Understand Single SIgn On

Here are my notes.

1. The sign on process protects the software and the data stored within or accessible by the software. from unauthorized access.
2. The sign on process is to ask the user to provide something, such as password, to verify himself.  Only those people who have the right answer is allowed to get in
3. SSO, from user perspective, is about using the same sign on password and sessions for multiple applications.
• SSO allows the users to not remember multiple passwords.
• SSO can be used to avoid the user to provide the same thing over again (within a browser or even across browser)
4. SSO, technically speaking, is to by pass the login screen from the applications and use a login screen from the SSO server.
• Once the SSO is enabled, the application login page should not be seen by the users.
5. SSO allows the user information (password) used for authenticating the user to stored centrally, not in each apps.  The sensitive information can thus be protected.
6. However, applications can ask the SSO server to provide additional attributes about the users
7. The login page redirection from the apps to SSO server is a typically way to enable SSO.
• If the SSO server is also providing a portal service, in the other word, the applications are listed centrally, the redirection from an application URL may not be important.
• We cannot avoid the users to use a browser bookmark to access to the application.  Redirection from the apps to SSO is almost always required.  Also.  It may be from any page, not just the specific login page
8. Browser Cookie is a way to make the browser to "remember".  It is used to communicate between the SSO server and the apps. 

Here are notes about SAML:

It defines a set of protocols (predefined communication dialog) among three players:

• The SSO provider
• The Application
• The Browser (User)

The flow among these three players like this:

1. A user attempts to access the application (using the provided URL)
2. The apps (transparent from the users)
• Receive the request
• Check if a session already exists
• If not, 
• Generate a SAML authentication request (an XML as defined in SAML2.0)
• A unique token is generated to identify this session 
• Encrypted token and next URL
• Redirect the Browser to the SSO URL. (Yes, Apps needs to store this somewhere) - Continue to #3
• If yes, the user is already authenticated and can exit out of the SSO process
3.  The SSO provider
1. Receive the SAML authentication request
2. Display the Login Screen - Challenging for credential
4. The user 
• Enters the answer / password
• Submit to the SSO site
5. The SSO Provider (transparent from the users)
1. Receives the user password and authenticates the user
2. If valid,
• Generate SAML response
• Encrypted uname, email, token, etc.
• Return the encoded response to browser  
3. If not, ask reattempt or return error message
6. The application
1. Validate the SAML request
2. (Optional?) Assertion Consumer Service (ACS) - can communicate to SSO provider via SOAP
3. Receive the user info from SSO
4. Perform session initialization, authorization, etc.
5. Return the resource (URL) that user requested