How would I use SSO in the following scenario: I have two servers running with the same application and centralized database. I log in to server No. 1 with the URL http://server1 and from server No. 1 I'm linking my URL to server No. 2 with http://server2. At this point, it asks for username and password; how can I use SSO to get around that?
Single sign-on (SSO) systems use session-based authentication tokens/cookies instead of username/password data to authenticate users among multiple systems. The tokens/cookies contain authentication information linked to individual users that are encrypted with a common key. The actual format of the token varies based on the product used, and each system that is SSO-enabled must have additional SSO software installed, or must be configured to accept these tokens/cookies in place of username/password. Plus the systems must be able to get to the key repository to encrypt/decrypt the token/cookie. So given the scenario above, as the user logs into http://server1, he or she is authorized access to information on the server based on his or her profile, and SSO software on the server adds a token/cookie to the user's browser. When the user connects to http://server2, the SSO software installed on this server recognizes the token/cookie in the browser-connect request, decrypts and verifies its validity, and, if the token/cookie is deemed OK, bypasses the authentication prompts and grants access to information on this server based on the user's profile.
While most enterprise SSO (eSSO) technologies today use proprietary architectures, there are two standard SSO technologies: federation and Kerberose. Both are well defined and provide generic SSO services, so any offering based on either architecture would fit the bill.
- Learn how to log in to multiple servers with federated single sign-on.
- Read more about using Kerberos as an authentication system for single sign-on.
This was first published in November 2009