So what is SAML? Well SAML stands for Security Assertion Markup Language and has become the predominant way that enterprises perform internet based Single Sign On (SSO) these days. Its been around for a while and there is plenty of documentation online that explains how it works. Still somehow every time I talk to someone about SAML and SSO, there is always some confusion. So here is an attempt at explaining the basic SAML flow in terms that you can hopefully remember.
Let's say that your rising kindergartner wants to join the soccer practice at school, what does he do? He goes to the teacher and asks if he could join the soccer practice. The teacher hands him a piece of paper and says please have your parents fill out this form and have them sign it. The kid brings that piece of paper to the parents, they look at it, consider his request, fill out the form, sign it and give it back to him, asking him to take it back to the teacher without messing with it. The kid takes the completed and signed form back to the teacher, who verifies it and lets the kid join the soccer practice. At the basic level this is exactly how SAML works -- just substitute the User for the kid, a Service Provider (SP) for the school teacher and an Identity Provider (IdP) for the parents.
Now, don't over think the analogy or expand too much upon it, I'm sure you can poke some holes; just use it to remember the basic flow of information.
When the User tries to access a protected resource at the Service Provider, the SP will check the user's domain and will generate a SAML Request redirecting the user to the Organization's Identity Provider. The IdP will verify the identity of the user (by way of login, if not already logged in) and will generate a SAML Assertion (containing a Federated ID) and send a SAML Response back to the SP. The SP will verify the SAML Assertion (the Federated ID), log the user in and will provider access to the protected resource. Now, in all these different redirects the original URL to the protected resource that the User was trying to access will be preserved and passed in as the Relay State (not directly as a URL, but as some binding to it). Once logged in (after verifying the SAML Assertion), the SP will forward the User to the original request URL as maintained in the Relay State. Here is a picture of the flow (borrowed from article referenced below):
For setting up SSO in Salesforce.com, along with examples of SAML Request and Response, Just In Time Provisioning, etc., check out the SSO Implementation Guide:
http://login.salesforce.com/help/doc/en/salesforce_single_sign_on.pdf
Finally, for setting up SSO for Desktop and Mobile apps with Salesforce, check out:
http://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth
Enjoy!
Let's say that your rising kindergartner wants to join the soccer practice at school, what does he do? He goes to the teacher and asks if he could join the soccer practice. The teacher hands him a piece of paper and says please have your parents fill out this form and have them sign it. The kid brings that piece of paper to the parents, they look at it, consider his request, fill out the form, sign it and give it back to him, asking him to take it back to the teacher without messing with it. The kid takes the completed and signed form back to the teacher, who verifies it and lets the kid join the soccer practice. At the basic level this is exactly how SAML works -- just substitute the User for the kid, a Service Provider (SP) for the school teacher and an Identity Provider (IdP) for the parents.
Now, don't over think the analogy or expand too much upon it, I'm sure you can poke some holes; just use it to remember the basic flow of information.
When the User tries to access a protected resource at the Service Provider, the SP will check the user's domain and will generate a SAML Request redirecting the user to the Organization's Identity Provider. The IdP will verify the identity of the user (by way of login, if not already logged in) and will generate a SAML Assertion (containing a Federated ID) and send a SAML Response back to the SP. The SP will verify the SAML Assertion (the Federated ID), log the user in and will provider access to the protected resource. Now, in all these different redirects the original URL to the protected resource that the User was trying to access will be preserved and passed in as the Relay State (not directly as a URL, but as some binding to it). Once logged in (after verifying the SAML Assertion), the SP will forward the User to the original request URL as maintained in the Relay State. Here is a picture of the flow (borrowed from article referenced below):
SAML 2.0 - Service Provider Initiated SSO
The above flow is known as the Service Provider initiated SSO in which the user first tries to access a resource at the SP and initiates the flow. A variation of this is the IdP initiated SSO where the user would login at the IdP and will click on a link to access the Service Provider. In that case, the IdP would generate the SAML Assertion when the user clicks on the Service Provider link and will take the user to the start page configured for the Service Provider. This start page at the SP should know how to validate the Assertion, automatically login the user and redirect to the home page. There is no Relay State involved here.
The key to all this is that the Service Provider and Identify Provider have already established a trust relationship by setting up the required information, importing certificates, etc. at the time of setup -- similar to how the kid's school knows that you are the parent by requesting for the child's birth certificate, completed and signed forms etc. at the time of registration :)
To understand in depth how SSO with SAML works in Salesforce.com, check out:
For setting up SSO in Salesforce.com, along with examples of SAML Request and Response, Just In Time Provisioning, etc., check out the SSO Implementation Guide:
http://login.salesforce.com/help/doc/en/salesforce_single_sign_on.pdf
Finally, for setting up SSO for Desktop and Mobile apps with Salesforce, check out:
http://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth
Enjoy!
Dealing with strategy these salesforce consultants process further. They crosses each milestones with the hard work. These SAML explanation is really helpful for continue communication.
ReplyDelete