A couple of clients and partners asked us whether Hypergate supports SAML, OAuth, OpenID in short one of the cloud SSO protocols. The question is very relevant when it comes to choosing a future proof solution. In the end you don’t want that people need to sign in manually whenever they consume a cloud based service like Microsoft, Salesforce, etc. This is especially true on a mobile phone, where typing in credentials is even more cumbersome than with a keyboard.
Yes, Hypergate can
The answer to the question is actually quite simple: yes, Hypergate can support SSO logins to cloud services. However there are a couple of preconditions that need to be met. Kerberos is a protocol used to authenticate users in an on-premise environment. The “standard” scenario here is when using a Microsoft Active Directory. The cloud service (e.g. Salesforce) will not be installed on-premise and cannot “talk” to the on-premise Microsoft Active Directory directly. Instead what is being done is that the login is federated. Basically you tell Salesforce that your users’ identity is provided by another service, rather than using the local Salesforce user directory. By delegating/federating the login Salesforce will not check the users’ credentials anymore by itself. But it will be trusting the configured system. In a nutshell Salesforce will be accepting everything that has been signed off by the configured identity provider.
If your identity provider supports on-premise authentication, more specifically Kerberos based authentication, Hypergate can take over the credential negotiation part. Once authenticated, the identity provider will immediately forward the federated request (e.g. using SAML, OAuth, OpenID, etc…). The user will be automagically be securely logged in to his cloud application.
Here a short clip showing the whole thing in action:
What you can see is a user that tries to authenticate to an Office 365 cloud application. The user’s account is setup to “federate” the request to an internal identity provider. Then the identity provider authenticates using Hypergate and the user is forwarded automatically to his cloud application. The best thing is that the user is not even aware that Hypergate is authenticating him/her in the background, it just works.
Hypergate is compatible with every idP that supports Kerberos based authentication, for example:
- Ping Identity
- Okta
In case you have any doubt whether your idP solution is supported, don’t hesitate to reach out to us and ask.
Certificate based authentication
Our experience when talking to customers and partners is that while the configuration to fetch ticket granting tickets for a given REALM with Hypergate using Username/Password is easy to setup. Most of the time is spent figuring out the correct configurations for certificate based authentication (CBA).
The advantages of certificate
based authentication are:
- A better UX:
As soon as the user unlocked the enterprise container, he/she can authenticate to every kerberized service without being prompted for input. - A Higher level of security:
The user does not need to remember/write down/input credentials.
We are happy to announce that starting with release Version 1.3 of Hypergate Professional. We included a certificate debugging/troubleshooting tool, that helps integrators to quickly spot the issue for the given configuration. The debugger checks the formatting of given CA’s and will analyze if the entire certificate chain up to the Root certificate validates and was configured correctly. What before would take you some digging in the logs, can now be achieved by simply clicking a button.
The release 1.3 also includes functionality to configure the entire certificate based authentication: By simply using a certificate alias or just selecting the correct certificate on the device. This means that if you are pushing the correct certificates to the android trust store (something you are doing anyways if you have self-signed certificates to secure your internal web services), you can configure Hypergate by just setting the alias of the certificate you want to use.
This will bring down complexity and save everyone time during configuration. Happy integration.
