Why SAML (Security Assertion Markup Language)?
Single Sign-On: Many organizations have multiple intranet servers with web front end. Though all servers interact with common authentication database such as LDAP, SQL databases, each server used to take authentication credentials from employee. That is, if employee logs into server1 and then goes to server2 employees are expected to provide credentials again to the server2. It may sound okay if the user is deliberately going to different servers. But, this is not good experience if there are hyperlinks from one server pages to other servers. Single Sign-On solves this issue. Once the user logs into a server successfully, the user does not need to provide his/her credentials when he/she accesses other servers. Single authentication with single sign-on is becoming common requirement in organizations.
Cloud Services: Organizations are increasingly adopting Cloud Services for cost reasons. Cloud Services are provided by third party companies. For example, salesforce.com provides Cloud service for CRM. Taleo provides cloud service for talent acquisition systems. Companies now have intranet servers, some cloud services from different cloud service vendors. Employees accessing the cloud service should not be asked to create accounts in the cloud service. It is expected that cloud service provider uses the its subscriber organizations authentication database to validate the users signing in. Many companies would not like to provide the access to their authentication database to cloud services directly. Also, many companies would not like their employees to provide their organization login credentials to cloud service for the fear of compromising the passwords, especially, senior and financial executives. This requires the need for cloud services to redirect the employees to login using companies web servers and use single sign on mechanisms to allow the users to access cloud services.
SAMLv2 (version 2 is the latest version) facilitates the single sign-on not only across intranet servers of the company, but also across services provided by cloud providers.
How does SAMLv2 work?
There are two participants in SAML world - Service Provider (SP) and Identity Provider (IDP). Service provider is referred to represent the intranet servers and cloud servers. Service provider provides some services to the authenticated users. Identify provider refers to the system which takes login credentials from the user and authenticates the user using local database or LDAP database or any other authentication database.
When the user tries to access the resources in service providers, SAMLv2 component of Service provider (SP) first checks whether the user is already authenticated. If so, it allows the access to its resources. If the user is not authenticated, then rather than providing login screen and taking credentials, it instructs the user browser (by sending HTTP Redirect response with new location header containing the identity provider URL) to redirect the request to the identity provider. Ofcourse SAMLv2 component of the SP needs to be configured with the IDP Provider URL beforehand by administrator. SAMLv2 component of SP generates SAML request (in XML form) and 'Relay State". It then adds these two to the location URL of the HTTP redirect response. Browser then redirects the request as per location header to the IDP. Now, IDP has the SAML request and Relaystate information.
IDP first checks whether the user is already authenticated with it. If not, it sends the login page to the user as part of HTTP response. Once the credentials are validated based on the authentication database, SAMLv2 component of IDP generates the SAML response with the result of authentication, principal name and attests the response using private key of its certificate by signing the SAML response. It also can add some more information about the user via attribute statements. It then sends both SAML response and relay state to the browser as response to the last HTTP request it got (which is typically the credentials request). IDP normally makes a HTTP page with embedded POST request with URL which is SP URL (which it got from the SAMP request), SAML response and relaystate (which it got before) and javascript which is used by browser to send the POST request. Browser gets this response and due to javascript it automatically posts the request to SP. This POST request contains the SAML response and RelayState.
Now SAMLv2 component of SP ensures that SAML response is valid by verifying the digital signature. Note that the public key (certificate) of IDP is expected to be configured in the SP beforehand by the administrator. Then it checks the subject name of principal and result of authentication. If result of authentication indicates 'success', then it sends HTTP redirect response to the browser with original URL (from relaystate) as location header. This makes the browser go the original URL to get hold of response.
Now onwards, user would be able to access the pages in the SP. If the user goes to another SP of the company, same process as above would be repeated. Since the user is already authenticated with the IDP, IDP does not take login credentials again. Since user does not see all the transactions that are happening underneath, he/she gets single sign-on experience.
By keeping the IDP in Enterprise premises, one can be sure that passwords are not given to any SPs whether they are intranet SPs or Cloud Service SPs.
SAMLv2 - Other SSO use cases:
The use case described above is called 'SP initiated SSO'. It is called SP initiated because user is trying to access the SP first. Other use case in SSO is 'IdP initiated SSO' . User access the IdP first. IdP authenticates the user and then user is presented with links to different SPs that user can access. When the user clicks on these special links, SAMLv2 component on the IDP generates the HTTP response with HTML page having POST binding to the SAMLv2 component of SP (It is called Assertion Consumer Service URL). SAMLv2 response is provided in the HTML page as one of the post fields. It adds 'RelayState' parameter with the URL that the user is supposed to be shown on the SP. Note that 'RelayState" in this case is unsolicited. There is no guarantee that the ACS in the SP will honor this parameter and also there is no guarantee that all ACSes treat the relayState as URL. But many systems expect the URL in the relayState (including Google Apps Cloud Service) and hence sending URL is not a bad thing.
Above two cases 'SP Initiated SSO' and 'IdP initiated SSO' are mechanisms to access the resource by single authentication. 'Logout' is another scenario. When user logs out (whether on a SP or on IdP), the user should be logged out on all SPs. This is called "Single Logout Profile". IdP is supposed to maintain all the SP information for which IdP was contacted for all users. When the user logs out on IDP, for all SPs in the user login session, it sends a logout request to 'Logout Service' component of SP. If user logs out on SP and indicates his willingness to logout on all SPs, then the SP in addition to destroying the user authentication context on the SP also redirects the user browser to IDP. As part of redirection, it also frames the logout request too to the IDP. IDP then destroys the context in the authentication context. If the user indicated that he would be like to be logged out from all SPs, then the IdP would send the logout requests over SOAP to all other SP in the user authentication context.
For more detailed information about SAMLv2, start with SAMLv2 Technical overview and SAMLv2 specifications. You can find them here:
http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
http://saml.xml.org/saml-specifications
IdP Proxy use case
So far the use cases described above talk about SP and IdP interaction via browser or directly. SAML does not prohibit IdP proxy use case where IdP proxy work as IdP for SPs and as SP for IdPs. Please see some links on this topic:
https://spaces.internet2.edu/display/GS/SAMLIdPProxy
Open Source SAMLv2 SP, IdP and IdP Proxy:
I find that OpenAM (fork of Sun OpenSSO) as one of the popular open source SSO authentication framework. You can find more information here:
http://forgerock.com/openam.html
IdP Proxy configuration is detailed here:
https://wikis.forgerock.org/confluence/display/openam/SAMLv2+IDP+Proxy+Part+1.+Setting+up+a+simple+Proxy+scenario
https://wikis.forgerock.org/confluence/display/openam/SAMLv2+IDP+Proxy+Part+2.+Using+an+IDP+Finder+and+LOAs
One more good site I found which details out IDP proxy and source code in Python:
http://www.swami.se/english/startpage/products/idpproxysocial2saml.131.html
Some good links, though not related IDP Proxy:
Google Apps as Service Provider and OpenAM as IDP: https://wikis.forgerock.org/confluence/display/openam/Integrate+With+Google+Apps
OpenAM as Service provider and Windows ADFS as IDP: https://wikis.forgerock.org/confluence/display/openam/OpenAM+and+ADFS2+configuration
Single Sign-On: Many organizations have multiple intranet servers with web front end. Though all servers interact with common authentication database such as LDAP, SQL databases, each server used to take authentication credentials from employee. That is, if employee logs into server1 and then goes to server2 employees are expected to provide credentials again to the server2. It may sound okay if the user is deliberately going to different servers. But, this is not good experience if there are hyperlinks from one server pages to other servers. Single Sign-On solves this issue. Once the user logs into a server successfully, the user does not need to provide his/her credentials when he/she accesses other servers. Single authentication with single sign-on is becoming common requirement in organizations.
Cloud Services: Organizations are increasingly adopting Cloud Services for cost reasons. Cloud Services are provided by third party companies. For example, salesforce.com provides Cloud service for CRM. Taleo provides cloud service for talent acquisition systems. Companies now have intranet servers, some cloud services from different cloud service vendors. Employees accessing the cloud service should not be asked to create accounts in the cloud service. It is expected that cloud service provider uses the its subscriber organizations authentication database to validate the users signing in. Many companies would not like to provide the access to their authentication database to cloud services directly. Also, many companies would not like their employees to provide their organization login credentials to cloud service for the fear of compromising the passwords, especially, senior and financial executives. This requires the need for cloud services to redirect the employees to login using companies web servers and use single sign on mechanisms to allow the users to access cloud services.
SAMLv2 (version 2 is the latest version) facilitates the single sign-on not only across intranet servers of the company, but also across services provided by cloud providers.
How does SAMLv2 work?
There are two participants in SAML world - Service Provider (SP) and Identity Provider (IDP). Service provider is referred to represent the intranet servers and cloud servers. Service provider provides some services to the authenticated users. Identify provider refers to the system which takes login credentials from the user and authenticates the user using local database or LDAP database or any other authentication database.
When the user tries to access the resources in service providers, SAMLv2 component of Service provider (SP) first checks whether the user is already authenticated. If so, it allows the access to its resources. If the user is not authenticated, then rather than providing login screen and taking credentials, it instructs the user browser (by sending HTTP Redirect response with new location header containing the identity provider URL) to redirect the request to the identity provider. Ofcourse SAMLv2 component of the SP needs to be configured with the IDP Provider URL beforehand by administrator. SAMLv2 component of SP generates SAML request (in XML form) and 'Relay State". It then adds these two to the location URL of the HTTP redirect response. Browser then redirects the request as per location header to the IDP. Now, IDP has the SAML request and Relaystate information.
IDP first checks whether the user is already authenticated with it. If not, it sends the login page to the user as part of HTTP response. Once the credentials are validated based on the authentication database, SAMLv2 component of IDP generates the SAML response with the result of authentication, principal name and attests the response using private key of its certificate by signing the SAML response. It also can add some more information about the user via attribute statements. It then sends both SAML response and relay state to the browser as response to the last HTTP request it got (which is typically the credentials request). IDP normally makes a HTTP page with embedded POST request with URL which is SP URL (which it got from the SAMP request), SAML response and relaystate (which it got before) and javascript which is used by browser to send the POST request. Browser gets this response and due to javascript it automatically posts the request to SP. This POST request contains the SAML response and RelayState.
Now SAMLv2 component of SP ensures that SAML response is valid by verifying the digital signature. Note that the public key (certificate) of IDP is expected to be configured in the SP beforehand by the administrator. Then it checks the subject name of principal and result of authentication. If result of authentication indicates 'success', then it sends HTTP redirect response to the browser with original URL (from relaystate) as location header. This makes the browser go the original URL to get hold of response.
Now onwards, user would be able to access the pages in the SP. If the user goes to another SP of the company, same process as above would be repeated. Since the user is already authenticated with the IDP, IDP does not take login credentials again. Since user does not see all the transactions that are happening underneath, he/she gets single sign-on experience.
By keeping the IDP in Enterprise premises, one can be sure that passwords are not given to any SPs whether they are intranet SPs or Cloud Service SPs.
SAMLv2 - Other SSO use cases:
The use case described above is called 'SP initiated SSO'. It is called SP initiated because user is trying to access the SP first. Other use case in SSO is 'IdP initiated SSO' . User access the IdP first. IdP authenticates the user and then user is presented with links to different SPs that user can access. When the user clicks on these special links, SAMLv2 component on the IDP generates the HTTP response with HTML page having POST binding to the SAMLv2 component of SP (It is called Assertion Consumer Service URL). SAMLv2 response is provided in the HTML page as one of the post fields. It adds 'RelayState' parameter with the URL that the user is supposed to be shown on the SP. Note that 'RelayState" in this case is unsolicited. There is no guarantee that the ACS in the SP will honor this parameter and also there is no guarantee that all ACSes treat the relayState as URL. But many systems expect the URL in the relayState (including Google Apps Cloud Service) and hence sending URL is not a bad thing.
Above two cases 'SP Initiated SSO' and 'IdP initiated SSO' are mechanisms to access the resource by single authentication. 'Logout' is another scenario. When user logs out (whether on a SP or on IdP), the user should be logged out on all SPs. This is called "Single Logout Profile". IdP is supposed to maintain all the SP information for which IdP was contacted for all users. When the user logs out on IDP, for all SPs in the user login session, it sends a logout request to 'Logout Service' component of SP. If user logs out on SP and indicates his willingness to logout on all SPs, then the SP in addition to destroying the user authentication context on the SP also redirects the user browser to IDP. As part of redirection, it also frames the logout request too to the IDP. IDP then destroys the context in the authentication context. If the user indicated that he would be like to be logged out from all SPs, then the IdP would send the logout requests over SOAP to all other SP in the user authentication context.
For more detailed information about SAMLv2, start with SAMLv2 Technical overview and SAMLv2 specifications. You can find them here:
http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
http://saml.xml.org/saml-specifications
IdP Proxy use case
So far the use cases described above talk about SP and IdP interaction via browser or directly. SAML does not prohibit IdP proxy use case where IdP proxy work as IdP for SPs and as SP for IdPs. Please see some links on this topic:
https://spaces.internet2.edu/display/GS/SAMLIdPProxy
Open Source SAMLv2 SP, IdP and IdP Proxy:
I find that OpenAM (fork of Sun OpenSSO) as one of the popular open source SSO authentication framework. You can find more information here:
http://forgerock.com/openam.html
IdP Proxy configuration is detailed here:
https://wikis.forgerock.org/confluence/display/openam/SAMLv2+IDP+Proxy+Part+1.+Setting+up+a+simple+Proxy+scenario
https://wikis.forgerock.org/confluence/display/openam/SAMLv2+IDP+Proxy+Part+2.+Using+an+IDP+Finder+and+LOAs
One more good site I found which details out IDP proxy and source code in Python:
http://www.swami.se/english/startpage/products/idpproxysocial2saml.131.html
Some good links, though not related IDP Proxy:
Google Apps as Service Provider and OpenAM as IDP: https://wikis.forgerock.org/confluence/display/openam/Integrate+With+Google+Apps
OpenAM as Service provider and Windows ADFS as IDP: https://wikis.forgerock.org/confluence/display/openam/OpenAM+and+ADFS2+configuration
1 comment:
Nice blog post..
Thanks for sharing here....
UDP Offload IP Core.
Post a Comment