Why is an external Pritunl server integrated with an on-prem installation? A callback is something the local server can handle.
What data is specifically transmitted there?
What happens if this service is not available?
This is an important point, if the functionality of a VPN/web app depends on an external service of Pritunl, many companies will not be able to use this.
We’ve exactly the same concerns. We don’t really understand why IdP connection cannot be fully managed by the self hosted application.
Moreover, I don’t see any agreement regarding the security of this external platform.
From technical perspective, as an example, since the OAuth flow is transiting through auth.pritunl.com, it means the token used to connect Pritunl app, downloading the profile, and setting the PIN code could be intercepted on this external component.
Also, do you use any kind of third party analytics solution ? Based on cookie found, it looks like you could use Amplitude solution somewhere.
Like @mat asked, I would be very interested to have more information about these external components, and all data exchanged with.
Could we imagine implementing the solution without any kind of connection with such external components ?
All single sign-on providers will rely on a third party, when using single sign-on the service will always be dependent on a third party. The single sign-on configurations will use auth.pritunl.com to protect the paid features in the enterprise subscription. If either the single sign-on provider or auth.pritunl.com were to go offline users would be unable to connect. There is a single sign-on outage page in the documentation explaining how to skip the single sign-on verification which would leave the profile authenticating only with the private keys.
Specifically only the Oauth and SAML authentication is done on the auth.pritunl.com server. All of the providers have additional authentication that is done on the Pritunl server often using API keys. This is not done on the auth.pritunl.com server and the API keys are never accessible to the auth.pritunl.com server. Duo authentication is done entirely on the Pritunl server. If the documentation is followed correctly all the authentication is scoped to basic user profile information and the auth.pritunl.com server will never have access to sensitive user information.
This design does provide additional compatibility with many Pritunl configurations and allows the Pritunl servers to move to different domains and IP addresses without effecting single sign-on access. It will also allow quickly patching authentication issues without requiring administrators to update the Pritunl server. Although the SAML authentication bypass vulnerability did not impact the Golang encoding/xml library used on auth.pritunl.com had this vulnerability effected Pritunl it could have been patched very quickly for all Pritunl servers. There is still an additional self shutdown system that will disable different components of a Pritunl server within an hour of the app.pritunl.com server providing notification. These features ensure a Pritunl server will never become vulnerable even if it is not updated.
Thanks for the explanation but unfortunately this doesn’t solve the problem.
The justification that locally installed VPN software only works with an external Pritunl service when using an IdP in order to protect Pritunl Enterprise functions may be correct in terms of content, but is more than questionable.
Of course, Microsoft, Google and Co. are also external services, but companies have a contract with them and a guaranteed SLA.
What you describe means in fact that a Pritunl cloud is required to run the VPN. There is no contract, no SLA, no data protection agreement, it is not even mentioned in the package overview.
I don’t know how familiar you are with ISO requirements and safety officers, but any company that has such standards will have to shut down such a solution immediately. In Europe there are also more far-reaching requirements (mentioned profile information), so it would even be a legal issue. It is not allowed to share any of these information with an external service without data protection contract.
We’ve spent a lot of time evaluating a good VPN solution and now there’s no other choice to take it offline. Not because we want it, but because such a construct does not pass any audit and we have to do it.
There is a policy of never analyzing or disclosing any customer information including for marketing or any other reason. Even when prospective customers ask for names of other companies using Pritunl this information is not provided. There’s no specific agreement or contract for this in the monthly subscriptions but it has always been the policy. There are several customers with customized annual contracts that do have these agreements in a contract. If it’s required that option is available, but it still applies to all Pritunl users.
There’s nothing rational about SLA or any other agreements. There’s endless examples of companies having security breaches and outages despite all the agreements and certifications. Often times it is a lower level employee who carelessly or sometimes intentionally causes the security breach. The policies and agreements can’t prevent it from occurring. The LastPass breach was caused by a RCE exploit on an employees work computer which then allowed access to internal infrastructure that didn’t have adequate mutli-factor authentication. LastPass had six third-party security certifications.
To the extent that any of it is important Duo multi-factor authentication can be configured. This should always be done for all systems by any company using single sign-on that requires a high level of security. This ensures that no one third party can cause a breach of the system. The Duo authentication is done entirely between the Pritunl server and Duo. Additionally support for device authentication with Webauthn is under development for Pritunl. It’s already available in Pritunl Zero and Pritunl Cloud. This will require an administrator to approve every device that is allowed to connect to the VPN without relying on any third party.
All of the Pritunl infrastructure exceeds any certification requirements. I’m the only person with access to the internal infrastructure and authentication is always done with physical YubiKeys. I have extensive experience in systems security and always follow the best security practices. My work computer isolates all activities between four Pritunl Cloud virtual machines. Any vulnerabilities in a web browser would also need to escape the virtual machine to access sensitive systems. Even my code editor runs in a virtual machine to limit the impact of malicious software libraries.