With so many websites and apps needing user authentication, Single Sign-On (SSO) is a great way to simplify the user experience. With SSO, a user provides their credentials only once. An app authenticates the user with an enterprise directory service. The next app that needs to authenticate the same user with the same enterprise directory service can simply rely on the previous authentication.
The majority of mobile SSO solutions have been developed for cloud-based apps using standards such as SAML or other similar protocols for authentication with an enterprise Active Directory. In the Active Directory infrastructure, however, the well-known security provider Windows Integrated Authentication with Negotiate - also known as Kerberos - is widely used and is enabled by default. Many apps, especially, Intranet apps, were not portable into mobile phone apps because the HTTP Negotiate authentication method (which can use Kerberos or NTLM) was missing on the mobile device framework.
Introduced with Samsung Knox v2.0, the Samsung Knox SSO SDK based on Kerberos supports SAML 2.0 and HTTP Negotiate Authentication using MIT Kerberos V5.
Note: The Samsung Knox Generic SSO framework and Centrify (MAS) SSO solution are now deprecated. Apps using these SSO solutions might still work but we can’t guarantee they will for future devices and Knox platform versions.
How it works
The Knox SSO framework supports the two app types.
- Enterprise app — Sends a user authentication request to an authenticator app. If the authenticator app returns an SSO token, the enterprise app can use it to access web-based app services.
- Authenticator app — Handles user authentication requests from enterprise apps. The app uses Kerberos to communicate, through either VPN or on-premise Wi-Fi, with the Active Directory. If the user is authenticated successfully, the authenticator app provides one of the following SSO token types to the enterprise app:
- Negotiate token, if the enterprise app is using HTTP Negotiate, which can be forwarded to an intranet service
- SAML response, if the enterprise app is using SAML 2.0, which can be forwarded to a cloud service
- Better user experience - User enters an AD username/password on the login screen once and gets smooth login sessions to all other whitelisted apps automatically. This reduces the number of login IDs and passwords that employees need to remember. IT admins can also enable SSO for the Knox container unlock method. Until the login sessions expire or the user is asked to authenticate again remotely by IT admin, there is no need to enter username/password again.
- Greater reach - Employees can now enjoy SSO, not only for SaaS and cloud-based apps but also for web-based intranet apps. Employees can securely access a company’s intranet homepage on their mobile phones, check emails, access the enterprise’s cloud and data sharing - all with just one log-in.
- Reduced cost - Lowers the IT cost from helpdesk calls about lack of access or password resets.
Next steps ...
- Browse the API Reference. This describes all the available API methods, grouped by Android package and Java class.
- Download a sample enterprise app. One shows how to get a SAML authentication token and use it to access the SaaS app and Google Calendar. The other shows how to get a Kerberos authentication token and use it to access an on-premise time server.
- Read the Developer Guide. This describes the different SSO solutions and how to use their SDKs.
Later, when you start coding and have questions, check the FAQs and Developer Forum for support.