OpenSAML

To make an application as a service provider (SP), you need to support SAML protocol.

It includes accepting the SAML message and generate the SAML message.

This API seems help the developers to hanlde SAML

OpenSAML2 User Manual

Here are examples:

SAML Single Sign On Scenarios

There are two main categories of scenarios:

• SP-Initiated: A user attempts to access a protected resource from the service provider
• IdP-Initiated: A user logged on and access the IdP and then access a protected resource from the service provider.

The second case is the one I mentioned earlier as portal.
Here is a web site with a comprehensive list of scenarios.

SAML and SaaS

SAML is an important standard used in the SaaS world.

Scenario before SAML

Traditionally, the user and password need to be created in the service provider.
The cloud service provider need to maintain the users.

If a user leave the company, we no longer want the user to be able to access the cloud service.
The problem is that the administrator within the company may not be aware or may not have the visibility or the control over the user store in the cloud service.

Remember that the client company may use multiple services.  The IT administrator in the client company will need to keep track all the services that the user has access and figure out how to get the user out of the systems.

The IT administrator really wants to have one switch to turn off all the access.

The things become more complicate as the user may just change the job role, and the IT administrator may need to change the permissions granted to the user in each of the service the user has access to.

If the cloud service does not integrate with the client company's IT system, the entire system won't flow very well.

--

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: