(2012-05-05) Claims Based Authorization And Federation Explained The Easy Way
Posted by Jorge on 2012-05-05
I found the article below and I thought to post it here also. The credits about this post of course go to the original writer. However, I also took the liberty to make some comments on what the original writer has written. Those comments can be found throughout the text and are specified with [Comment From Jorge].
ORIGINAL SOURCE: SAML WebSSO & Federation Made Easy
This week I found myself on a SalesForce/SAML/Federation journey which turned out to be very enlightening. Until a few days ago I really had no idea how SAML or Federation worked and it took me a few hours to get my head around it, so I’m going to try explain SAML in a way that’s easy to understand.
SAML 2.0 (Security Assertion Markup Language).
- Company A (Service Provider – SP) has a web application
- Company B (Identity Provider – IdP) has a database of people who need to access Company A’s application
[Comment From Jorge]: Sometimes an SP is also called a Relying Party (RP) and an IdP is also called Claims Provider (CP). Don’t you just love all those standards!?
We have a few options here:
- Company A could create a new database of people with usernames and passwords within the web application
- We could synchronize the database of people including their usernames and passwords from Company B (IdP) to Company A (SP)
- We could make a link from the web application to Company B’s database of people and do lookups in real-time
- We could tell the web application at Company A to trust users who come from Company B
Options 1 through 3 are pretty crappy. Option 4 is called federation and it’s cool.
[Comment From Jorge]: Option 1 and 3 is indeed crappy. However, option 2 may be required when either the Claims Based Application (an application that understands and consumes claims) requires a representation of the user (a so called place holder account or a shadow account), such as for example Office 365, or a Token Based Application (an application that does not understand and also does not consume claims, but rather leverages Windows style authorizations) is being used.
Here’s what happens (part analogy, part reality):
Both companies have a pair of keys. A public key and a private key. Once something is locked with the private key only the corresponding public key can open it. Company A has a copy of Company B’s public key and vice versa.
[Comment From Jorge]: In this case we are talking about the so called token signing certificate (ADFS term, in other federation solutions it may be called differently). Whenever a Security Token Service (STS) issues a security token with all kinds of claims, the issuing STS signs the token with the private key of its token signing certificate. The receiving STS (in this case) or an application, that has a federation trust setup with the issuing STS, verifies the security token received from the issuing STS by using the public key of the issuing STS’s token signing certificate. So, with this I can now say that the federation trust is setup between STS’es through the token signing certificates on either side. The word “lock” used by the original writer is in my opinion incorrectly used. Another possibility is to encrypt the security token for additional protection (this is by the way not mandatory to setup a federation trust), but both sides of the federation must be able to support this. In that case the issuing STS encrypts the security token with the public key of the receiving STS’s encryption certificate and when the receiving STS receives the security token it should be able to decrypt the encrypted security token by using the private key of its token encryption certificate. Again the token encryption (or decryption) certificate term is an ADFS thing. I do not know if its called the same in other federation solutions.
A user in Company B (IdP) tries to access the web application at Company A (SP). The web application looks for a cookie in the user’s browser to see if he is already authenticated, he is not so the web application (SP) redirects the browser to Company B’s IdP, telling him – “Go and get a ticket!”
[Comment From Jorge]: In reality, the application at company A (SP) redirects the user to the STS trusted by the application, which is by the way also the STS at company A (SP). If the STS at company A (SP) already knows the user is coming from company B (IdP) (through information in the user’s cookie) the STS at company A (SP) redirects the user to the STS at company B (IdP). If the STS at company A (SP) does not yet know where the user is coming from, the STS at company A (SP) performs so called home realm discovery (HRD) by asking the user to provide some information that enables the STS to determine where the user is coming from. This can be done by selecting a trusted STS from a list (all configured federation trusts disclosed, but no additional management needed) or by entering the company name or e-mail address (preferred) (no federation trusts are disclosed, but addition management is needed as mappings are needed between e-mail suffixes and trusted STS’es). As soon as the STS at company A (SP) determines where the user is coming from, it redirects the user to the trusted STS from, in this case, company B (IdP).
The browser goes to Company B’s IdP who authenticates the user against Company B’s database of users. The IdP at Company B locks the user’s employee ID with his private key, gives it to the browser and tells him – “Here’s your ticket now go back to the SP you came from!”
[Comment From Jorge]: The so called company B’s (IdP) database of users could be Active Directory (AD). In case of using ADFS v2, it MUST be AD, as ADFS only supports AD as an authentication store. In the case of ADFS v1.x, it can be either AD or ADLDS/ADAM. ADFS v2, however, does support ADLDS as an attribute store. An authentication store is a store that can authenticate a user and an attribute store does not authenticate a user, but may provide additional information in attributes that ADFS can leverage in claims. In this case the STS at the IdP issues the user a security token with claims and signs the security token with the private key from its token signing certificate to prove that the security token was issued by an STS trusted by the receiving STS.
The browser goes back to the web application (SP) at Company A and presents his ticket. The SP uses Company B’s public key to unlock the ticket. The web application says to himself - “It works! This user MUST have come from Company B because otherwise this public key could NOT have unlocked this ticket. And look, the ticket contains an employee ID and I have a rule that says that this employee ID is allowed access!” And so the web application gives the browser a cookie which allows him access.
[Comment From Jorge]: In this case the STS at company B (IdP) redirects the user back where he came from and in this case it is the STS at company A (SP). This STS at company A (SP) checks the security token is indeed from a trusted STS at company B (IdP) by using that trusted STS’s public key from its token signing certificate. When the check is positive, the STS at company A (SP) transforms the claims in the security token in any way as configured and issues a new security token with new claims and it also signs the new security token with the private key from its token signing certificate. It then redirects the user back to the application.
In SAML the ticket is called an Assertion. In this case we sent the Employee ID but any other user-unique attribute could be used, it just needs to be agreed between the 2 parties.
In reality the web application might not support SAML directly but instead maybe protected by a federation product which takes care of the SAML SP stuff. The IdP stuff will also likely be handled by a federation product which is backed by some kind of LDAP directory or maybe SQL. The browser cookie stuff mentioned above is outside the scope of SAML but I included it for completeness – It’s typical of how these things work.
The neat thing about federation is that you don’t need any links between Company A and Company B. Once the federation trust is established everything else takes place “browser to SP” and “browser to IdP” through a series or re-directs and http POSTs.
Ok so that’s SAML. Actually there are a lot more parts to it than that but that’s the way it’s most commonly used today i.e. for WebSSO. Now that you have the concept, you can dig into the technical details.
I found Google’s explanation useful:
and Wikipedia :
The best way to learn this stuff is to give it a go. Check out Shibboleth which is an open source SAML SP and IdP implementation. I’ve got the Shibboleth SP side talking to ADFS 2.0 as the IdP but I haven’t played with the Shibboleth IdP yet.
Next time I’ll show you how to put SAML to use with Active Directory Federation Services 2.0 and cloud provider SalesForce. In the mean time feel free to ask questions or make corrections.
[Comment From Jorge]: Also have a look at some Microsoft documentation found through the following links:
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########