Device single sign-on (SSO)
Single sign-on (SSO) enables users to access multiple resources (that is, applications and adapter procedures) by authenticating only once.
When a user successfully logs in through an SSO-enabled login module, the user gains access to all resources that are using the same login module, without having to authenticate again for each of them. The authenticated state remains alive as long as requests to resources protected by the login module are being issued within the timeout period, which is identical to the session timeout period.
Device authentication
The SSO feature requires the use of device authentication. This means that for a protected resource that needs to be protected with SSO, there must also be a device authentication realm in the securityTest protecting the resource in authenticationConfig.xml. Device authentication should take place before the SSO-enabled user authentication.
Supported devices
SSO is supported on Android, iOS, Windows 8, and Windows Phone 8 devices.
Performance
When we use the single sign-on feature, the load on the database might increase, and you might have to adjust the database configuration.
Implementing a custom authentication to support SSO
To allow SSO to operate on the custom authentication classes (authenticator and loginModule) we must:
- Make all fields in the class transient except for those fields that are being used by the following methods:
- WorklightAuthenticator.processRequestAlreadyAuthenticated(HttpServletRequest, HttpServletResponse)
- WorklightAuthLoginModule.logout()
- Mark the authenticator and loginModule classes (and any class referred to by those classes that is not transient after performing step 1) with the class annotation @DeviceSSO(supported = true) .
- Configure device single sign-on
Single sign-on (SSO) is a property of a login module. We can enable single sign-on for custom security tests and for mobile security tests.
Parent topic: MobileFirst security framework