LiveTime Single Sign-on (SSO) and SAML
LiveTime recently announced SAML based single sign-on (SSO) for LiveTime 6.1. What does this mean for your business and how can this be easily leveraged in existing environments?
Single Sign-On technologies, typically implemented using SAML or SAML2 specifications, streamline the end-user experience by granting access to resources without forcing users to re-authenticate with each application. Such a setup consists of, an IdP (Identity Provider), which manages the login session and is the source of user information along with one or more SPs (Service Providers) which manage resource access. SP’s are present with protected resources and handle the heavy lifting of challenging users for authentication if required or otherwise validating SSO sessions and dealing with other security concerns of such a configuration. This information is then filtered down to the protected applications and/or resources which can leverage the provided data to grant access to resources, bypassing another application login cycle.
With the Single Sign-On components doing all the heavy lifting, Java web applications (Servlets) need only leverage the information communicated using HTTP session headers. Using HTTP Session headers is a standard extension of SSO technologies, which support various methods of passing user information to protected resources. These can be named at the users discretion and configured to contain any information a protected application may require (subject to privacy policies of the implementing organization). This technique of passing user information to applications is implemented in most SAML2 Single Sign-On implementations, both free implementations (eg. Shibboleth, JOSSO) and commercial (eg. CA SiteMinder, Oracle Identity Manager, Novell SecureLogin).
LiveTime takes the complexity out of setting up single sign-on by providing direct access to the key attributes required for each SSO provider.
Simply login as a Administrator and select SSO in the menu. First, enter the Session ID of your Identity Provider. These are unique headers passed inside the HTTP headers and uniquely identify each provider, such as shibsessionid for Shibboleth. Then provide the user name identifier (usually uid) followed by the users email, which is used to validate the username.
Now you can simply turn on Single Sign On and test the logins. If everything has been correctly setup at the Identity Provider level and it is correctly intercepting logins, LiveTime will seamlessly pass the user into the application and bypass the login screen entirely.
Since this process is handled at the header level within LiveTime nothing else is required. SSO controls within your provider are now responsible for controlling the security around application access.