Thursday, March 14, 2013
ADFS : Using the SAML NameID to map IdP / SP claims
Imagine two companies: Fabrikam and Contuso. Fabrikam has a SaaS application in the cloud that Contuso wants to use. Fabrikam supports SAML authentication and is a SP. Contuso uses ADFS as an IP.
So all the pieces are in place and it should just work no problem. Dream on.
There needs to be a “primary key” that links the two companies together for a session.
Assume Contuso has an employee – the ubiquitous Joe Bloggs - and Joe needs access to the application.
So Contuso has to send Fabrikam a table of users – among which is Joe Bloggs. This table can be sent as XML, xls, text or whatever.
Fabrikam imports these users into the Contuso section of their database.
They also have to agree on what attribute of each user is the primary key e.g. sAMAcountName, email address, AD GUID …
Assume they choose email – this is the NameID.
So when Fabrikam get an AuthNResponse from Contuso, they extract the NameID and use that as the key into their table.
There is one further complication. The SAML spec. allows the NameID to be sent in a number of formats e.g. Unspecified, Email, X509 Subject Name…
This is important. If one side expects the email format e.g. email@example.com and the other side is expecting X509 Subject Name e.g. CNfirstname.lastname@example.org, OU=Dev,O=Contuso,C=NZ, you can predict that there will be problems.
So they both have to agree. Assume they choose email address.
To configure this in ADFS:
Configure the email address as the normal “Send LDAP Attributes as Claims”.
Then configure a “Transform an Incoming Claim” rule which takes “Incoming Claim Type” of email and maps it to “Outgoing Claim Type” of NameID which has an “Outgoing NameID Format” of email.