We will explain how claim rules work in ADFS by an example.

You have a relying party that currently uses AD as its Claims Provider and it requires AD to return several attributes. See below:

As you can see above, one of the attributes is called "SAM-Account-Name". We will use this attribute as an exmaple.

The attribute "SAM-Account-Name" is an AD attribute, and it is mapped to "Name ID" as required by the Relying Party.

Now, if the Claims Provider for this Relying Party is changed from AD to DualShield, then you need to get "SAM-Account-Name" from DualShield and mapped it to "Name ID"

Where does DualShield get the value of "SAM-Account-Name"? Ultimately, DualShield has to get the "SAM-Account-Name" from AD and return it as a SAML attribute.

What is "SAM-Account-Name"? It is in fact commonly known as user's login name. 

So, this is the process: AD Attribute → SAML Attribute → Claims Provider Attribute → Relying Party Attribute

  1. AD Attribute → SAML Attribute: DualShield retrieves the user's login name, i.e. "loginName" attribute from AD, then returns it to ADFS as a SAML attribute. Let's call it "samAccountName"
  2. SAML Attribute → Claims Provider Attribute: In ADFS, the Claims Provider receives the attribute, i.e. "samAccountName". It transform this incoming claim to an outgoing "Name ID" attribute
  3. Claims Provider Attribute → Relying Party Attribute: In ADFS, the Relying Party receives the attribute, i.e. "Name ID". It transform this incoming claim to an outgoing "Name ID" attribute


Implementation

Stage 1 - AD Attribute → SAML Attribute


Stage 2: SAML Attribute → Claims Provider Attribute 


Stage 3: Claims Provider Attribute → Relying Party Attribute









  • No labels