locked
Claim rule clarification RRS feed

  • Question

  • Hi, I am new the ADFS cliam rules and are trying to understand the following.

    In one of our relying party trust in our ADFS server, we have 2 claim rules, Send ldap attributes as claims rule to do email to email mapping and Transform an incoming claims rule to transform email to name ID. I saw that, under the Send ldap attributes as claims rule, name ID is available in the outgoing claim type. That means we can map email to name ID from the Send ldap attributes as claims rule. Then why we still need Transform an incoming claims rule to transform email to name ID?

    Thanks

    Monday, December 10, 2018 9:14 PM

Answers

  • Without the transform rule:

    	<Subject>
    			<NameID>test@piaudonn.com</NameID>
    			<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    				<SubjectConfirmationData NotOnOrAfter="2018-12-21T13:55:17.868Z" Recipient="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" />
    			</SubjectConfirmation>
    		</Subject>

    With the transform rule:

    		<Subject>
    			<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test@piaudonn.com</NameID>
    			<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    				<SubjectConfirmationData NotOnOrAfter="2018-12-21T13:59:38.340Z" Recipient="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" />
    			</SubjectConfirmation>
    		</Subject>

    Notice the NameID field in the XML. One has the Format properties one hasn't. And the transform rule is here for that. It is completely up to the application developer to require or not a specific format. The specs say it MAY be used (not it MUST nor it SHOULD):

    https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

    So you should ask this question to the owner of the application you are creating a trust with. 


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Marked as answer by hkg04 Monday, December 24, 2018 2:24 AM
    Sunday, December 23, 2018 2:34 PM

All replies

  • Hello,

    The claim rules depend of what the relying party awaits to receive.

    Maybe the application need email to provision user, map user to internal account users, etc.


    Blog : itpro-tips.com
    itpro_tipscom


    • Edited by ITPro-Tips Tuesday, December 11, 2018 12:38 AM
    Tuesday, December 11, 2018 12:37 AM
  • I realized that that. What I don't get is if you can map email to name ID simply using the send ldap attributes as claims rule, whey do I need to do the email to email mapping first by using the above rule and then transform the email to name ID afterward.
    Tuesday, December 11, 2018 3:43 AM
  • Before you can transform a claim, this claim has to be on the claim pipeline.

    So you get email addresses value (send LDAP...) -> email adress is in the claim pipeline -> transform the claim email address


    Blog : itpro-tips.com
    itpro_tipscom

    Tuesday, December 11, 2018 11:14 PM
  • Sorry for the late reply.

    Is the transform an incoming claim rule mandatory? I asked before more the RP require that rule transform the user login (either it is email or UPN) into NameID. When I looked at the Linkedin Learning ADFS SSO configuration, they don't need the transform rule. Instead, there is only a mapping for UPN to Name ID in the Send LDAP attributes claim rule.

    Thanks

    Monday, December 17, 2018 4:34 PM
  • Incoming transforms aren't mandatory per se, but depending on what you are doing, they are useful. For example, let's say you don't want to change the values of attributes in Active Directory, but you want to send values out the door as if they were. You can construct these values on the fly. The template description in the UI elaborates:


    edit for clarification: You do have to have incoming rules, but there is no obligation to do transformations.

    Mike Crowley

    My Blog | MikeCrowley.US

    Baseline Technologies | Baseline.Consulting

    Being ignorant is not so much a shame, as being unwilling to learn

    -Ben Franklin



    • Edited by Mike Crowley Wednesday, December 19, 2018 6:23 AM
    Wednesday, December 19, 2018 6:12 AM
  • Thanks, the part that I don't understand is if you can map LDAP attribute to NameID (requirement for most RP endpoint), then why use the extra transform rule to transform the attribute to NameID? I saw that many cloud apps does require the transform rule on ADFS.
    Wednesday, December 19, 2018 3:52 PM
  • I think you'd need to provide specifics (what KB are you looking at) for a better answer, but one example I had was for SAS:

    By default, ADFS sends the NameID attribute in an “unspecified” format. This doesn’t matter to any of the other relying parties we had configured with the org’s ADFS farm, but apparently the SAS application throws an error when the format isn’t specifically articulated. While this can be done on a farm-wide level, I was instead able to create a set of transformation rules which add the format type of “persistent”.



    Mike Crowley

    My Blog | MikeCrowley.US

    Baseline Technologies | Baseline.Consulting

    Being ignorant is not so much a shame, as being unwilling to learn

    -Ben Franklin


    • Edited by Mike Crowley Thursday, December 20, 2018 8:58 PM
    Thursday, December 20, 2018 8:58 PM
  • The documentation I have with Linkedin Learning is in PDF format. So I just pasted the claim rule configuration below. There isn't any requirement for adding a Transform an incoming claim rules for the SSO setup.

    

    When I searched on the web, all the adfs relying party trust configuration involving setting up a transform an incoming claim for NameId. However, all these instructions only tell you how to setup the rule but didn't say why you need to create these rules. Below are the ones that uses transform incoming claim.

    https://docs.pivotal.io/p-identity/1-7/adfs/config-adfs.html

    https://docs.mattermost.com/deployment/sso-saml-adfs.html

    https://docs.servicenow.com/bundle/geneva-servicenow-platform/page/integrate/saml/task/t_ConfigureADFSClaimRules.html

    Friday, December 21, 2018 3:40 AM
  • It has to do with the relying party applications and with the underlying federation protocols.

    When you have no Claim Issuance Policy, the application will have no idea who the user is. The app will just have the confirmation that the user was in fact authenticated. Sometimes it is enough for some applications. Like an Intranet website for which you want to enable the access to all authenticated users without expecting do customization or personalization.

    Then when the application needs to know something about the user, you need to issue claims. And there, the underlying protocol matters.

    With WS-Fed trusts, you can send whatever and the application developer on the application side needs to map one of them with some sort of identifier. So the application developer will ask the ADFS admin to issue a specific claim type with the type of value expected (like email, name etc...).

    When the trusts is using SAML-2, there are written specifications for what to send to identifier a user. And this is the claim type NameID. As an ADFS admin, you can put whatever you want in it as long as it enabled the users to be uniquement identified. Application developers should share with the ADFS admin the requirement of their NameID policy. And contrary to WS-Fed which does not type its claims or expect a specific format for the values, SAML-2 and the NameID claim can have a format. And the applications will reject the NameID if it doesn't stick to the expected format (which is specified in the NameID policy that the application developer should share). So for SAML, the following rule:

    Translate in the token as:

    <?xml version="1.0" encoding="utf-16"?>
    <samlp:Response ID="_13c3bced-73c0-4edd-bb7d-51281a608200" Version="2.0" IssueInstant="2018-12-21T13:50:17.868Z" Destination="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    	<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sts.piaudonn.com/adfs/services/trust</Issuer>
    	<samlp:Status>
    		<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    	</samlp:Status>
    	<Assertion ID="_e295017c-6309-4530-ae0e-d58e0562bfac" IssueInstant="2018-12-21T13:50:17.868Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    		<Issuer>http://sts.piaudonn.com/adfs/services/trust</Issuer>
    		<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    			<ds:SignedInfo>
    				<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
    				<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
    				<ds:Reference URI="#_e295017c-6309-4530-ae0e-d58e0562bfac">
    					<ds:Transforms>
    						<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
    						<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
    					</ds:Transforms>
    					<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
    					<ds:DigestValue>teikOShTU8oQvH0iqzwxhTR+iQ03SdPNG9mbYNEZ46w=</ds:DigestValue>
    				</ds:Reference>
    			</ds:SignedInfo>
    			<ds:SignatureValue>EgGXeoqiod8hz4HJ96Xfgc1BzhOTy+hrfPvvMcSdZDpzvphtaEjYOHKOOkfTQY7texjFC8z/5nJLnz2eenYJEpp5c+MDEuGKH5m0sQypt53SUZpeJDBifF6CrcpdCyvL4/GSfg40ApWLyOILXeyrlImjB2tri53qAQ5pt0rU218dKnm8KWnR04ksQ0UK50gbG8U/4COoqF2CxuzzkwsW28G4hJUfMtISpmik+FPE4FTsfRtFPMFsuv/GJJ+KYmSqtHKwWbpZEFjxUAw7qzwsVIdpl4EF6KMGwhyhxwPN2DmFjC7YEclMQDBcpA+tnEYlzZ7QX73ePqLB1wUMfZnGAA==</ds:SignatureValue>
    			<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    				<ds:X509Data>
    					<ds:X509Certificate>MIIC3DCCAcSgAwIBAgIQY2y8s+BoHI1GMTisACOeVzANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBzdHMucGlhdWRvbm4uY29tMB4XDTE4MDgzMTE5MzMzOVoXDTE5MDgzMTE5MzMzOVowKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gc3RzLnBpYXVkb25uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKUJLDMurDL98gV8bwjalx394i55f0evhcHL+dQK/rjYaYmx16TRTWtnLm0f+UKjx5+Yz3S5Lwa9oS1wSZta94utVV6rzbR0UZHysSyJhl1tKHw+699k3Qsaj+EeoARznLCVoeJoFd7Vg0HeHzTh9nRl3d0iBuHl6/qrhWKqHzAR1h5RTejd2fe3SahXgpD1WQ978z/ErQP+MX6gXjHrvj3UpdX8Wj+QvEG5AAZx2HyyIOovwUVf2TBymhPJHMoZMfdB73XydfMqGVK+xTmPib0P7TiEAB8ZDZEVVrPbnFLGnNeNwG4wAGGNr9+8VSQ7LCMNvLL734c453Uf/49rt5kCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAg+KV4OgqepTJ1hkzhIiz7PbLrjzt19XEEEE846XHlL16zLW9DsLYr5ElXc2YkSiC8SLy2ZTOpMFCSHS0ZjgQMvgXko656ZCFBVKfJmBe6PHdnXK5/0sKqF/fGFrifYjitzgN3n+hiksjaG5A2qTBeWbsgGl+malUkO96hQfmiNvFtk/OImrPnhHWFT/WUtXVIjTLHBH3uLCnlLCwATz1Ugrt2PGlE1MxHgnj8OsSdy6+x1PsH8UbiX/vza0gtznR2tZBhydsB8WcjNwC1ht7RTPfswAnQfG3lDVimlgxzOvzNWyjB/doRN/qa9NTAjRc/ydiTgvI0dYYMAdnuFKwGQ==</ds:X509Certificate>
    				</ds:X509Data>
    			</KeyInfo>
    		</ds:Signature>
    		<Subject>
    			<NameID>test@piaudonn.com</NameID>
    			<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    				<SubjectConfirmationData NotOnOrAfter="2018-12-21T13:55:17.868Z" Recipient="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" />
    			</SubjectConfirmation>
    		</Subject>
    		<Conditions NotBefore="2018-12-21T13:50:17.868Z" NotOnOrAfter="2018-12-21T14:50:17.868Z">
    			<AudienceRestriction>
    				<Audience>urn:microsoft:adfs:claimsxray</Audience>
    			</AudienceRestriction>
    		</Conditions>
    		<AuthnStatement AuthnInstant="2018-12-21T13:50:17.837Z" SessionIndex="_e295017c-6309-4530-ae0e-d58e0562bfac">
    			<AuthnContext>
    				<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
    			</AuthnContext>
    		</AuthnStatement>
    	</Assertion>
    </samlp:Response>

    Now sending the UPN as a NameID with a specified format:

    This results in the token as:

    <?xml version="1.0" encoding="utf-16"?>
    <samlp:Response ID="_2a26754f-513c-4002-b495-f7a1f04e1f61" Version="2.0" IssueInstant="2018-12-21T13:54:38.340Z" Destination="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    	<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sts.piaudonn.com/adfs/services/trust</Issuer>
    	<samlp:Status>
    		<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    	</samlp:Status>
    	<Assertion ID="_6cc0aece-a43c-4664-baf4-e237d41202d9" IssueInstant="2018-12-21T13:54:38.340Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    		<Issuer>http://sts.piaudonn.com/adfs/services/trust</Issuer>
    		<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    			<ds:SignedInfo>
    				<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
    				<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
    				<ds:Reference URI="#_6cc0aece-a43c-4664-baf4-e237d41202d9">
    					<ds:Transforms>
    						<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
    						<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
    					</ds:Transforms>
    					<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
    					<ds:DigestValue>HIaPSzFK6lDptZQHLtzY9KJ1EvCAlcBi0uCQDXglzC8=</ds:DigestValue>
    				</ds:Reference>
    			</ds:SignedInfo>
    			<ds:SignatureValue>VoqFftnh7FFjnHF0BobskY6I1TRBDD7vB6z4vwRoT0Ute6gOvysq/AASFEp0GCkN0gHJakbbtmMfkzTqwLgOl8uf1weAHiKq+VmqgPR/hq6ESgMh+9++vzppcLQoI4CTqRR+Gz1FRB0DmbLNR4gL/28KSof+jmNwnccvz7KIopKfO9tzpxabJFJUIfGy0p/SlzKEDT1rr3lYEz5FfLqFORzJXp6tKLysRRcQGR2+5KxuYBjVTxy+Mj8OuYkFGyfVm88nS6S+fB7H5IfLG5ag7CiLZsOV95VUaUI3FCXCqPDnfH/Hnf72eE49Q9t8dB73Mj9h2AhXK8Mn2CJ3dAAVaA==</ds:SignatureValue>
    			<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    				<ds:X509Data>
    					<ds:X509Certificate>MIIC3DCCAcSgAwIBAgIQY2y8s+BoHI1GMTisACOeVzANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBzdHMucGlhdWRvbm4uY29tMB4XDTE4MDgzMTE5MzMzOVoXDTE5MDgzMTE5MzMzOVowKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gc3RzLnBpYXVkb25uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKUJLDMurDL98gV8bwjalx394i55f0evhcHL+dQK/rjYaYmx16TRTWtnLm0f+UKjx5+Yz3S5Lwa9oS1wSZta94utVV6rzbR0UZHysSyJhl1tKHw+699k3Qsaj+EeoARznLCVoeJoFd7Vg0HeHzTh9nRl3d0iBuHl6/qrhWKqHzAR1h5RTejd2fe3SahXgpD1WQ978z/ErQP+MX6gXjHrvj3UpdX8Wj+QvEG5AAZx2HyyIOovwUVf2TBymhPJHMoZMfdB73XydfMqGVK+xTmPib0P7TiEAB8ZDZEVVrPbnFLGnNeNwG4wAGGNr9+8VSQ7LCMNvLL734c453Uf/49rt5kCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAg+KV4OgqepTJ1hkzhIiz7PbLrjzt19XEEEE846XHlL16zLW9DsLYr5ElXc2YkSiC8SLy2ZTOpMFCSHS0ZjgQMvgXko656ZCFBVKfJmBe6PHdnXK5/0sKqF/fGFrifYjitzgN3n+hiksjaG5A2qTBeWbsgGl+malUkO96hQfmiNvFtk/OImrPnhHWFT/WUtXVIjTLHBH3uLCnlLCwATz1Ugrt2PGlE1MxHgnj8OsSdy6+x1PsH8UbiX/vza0gtznR2tZBhydsB8WcjNwC1ht7RTPfswAnQfG3lDVimlgxzOvzNWyjB/doRN/qa9NTAjRc/ydiTgvI0dYYMAdnuFKwGQ==</ds:X509Certificate>
    				</ds:X509Data>
    			</KeyInfo>
    		</ds:Signature>
    		<Subject>
    			<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">piaudonnmsdn@piaudonn.com</NameID>
    			<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    				<SubjectConfirmationData NotOnOrAfter="2018-12-21T13:59:38.340Z" Recipient="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" />
    			</SubjectConfirmation>
    		</Subject>
    		<Conditions NotBefore="2018-12-21T13:54:38.340Z" NotOnOrAfter="2018-12-21T14:54:38.340Z">
    			<AudienceRestriction>
    				<Audience>urn:microsoft:adfs:claimsxray</Audience>
    			</AudienceRestriction>
    		</Conditions>
    		<AuthnStatement AuthnInstant="2018-12-21T13:54:38.309Z" SessionIndex="_6cc0aece-a43c-4664-baf4-e237d41202d9">
    			<AuthnContext>
    				<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
    			</AuthnContext>
    		</AuthnStatement>
    	</Assertion>
    </samlp:Response>

    In this last example, the UPN is already available so I don't have to create a rule to extract it (it is coming from the Acceptance Transform rules set on the Active Directory Claim Provider trusts, there by default).


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, December 21, 2018 1:58 PM
  • Thanks

    To put it the simplest form to ask.

    The SAML endpoint from the relying party is expecting NameId from Claim Provider. If the ADFS Send LDAP attribute as claims rule can map Email address to NameId as outgoing claim, why would most relying party still require the Transform rule to transform the outgoing claims (in this case Email) to NameId?

    Saturday, December 22, 2018 5:00 PM
  • Without the transform rule:

    	<Subject>
    			<NameID>test@piaudonn.com</NameID>
    			<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    				<SubjectConfirmationData NotOnOrAfter="2018-12-21T13:55:17.868Z" Recipient="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" />
    			</SubjectConfirmation>
    		</Subject>

    With the transform rule:

    		<Subject>
    			<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test@piaudonn.com</NameID>
    			<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    				<SubjectConfirmationData NotOnOrAfter="2018-12-21T13:59:38.340Z" Recipient="https://adfshelp.microsoft.com/ClaimsXray/TokenResponse" />
    			</SubjectConfirmation>
    		</Subject>

    Notice the NameID field in the XML. One has the Format properties one hasn't. And the transform rule is here for that. It is completely up to the application developer to require or not a specific format. The specs say it MAY be used (not it MUST nor it SHOULD):

    https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

    So you should ask this question to the owner of the application you are creating a trust with. 


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Marked as answer by hkg04 Monday, December 24, 2018 2:24 AM
    Sunday, December 23, 2018 2:34 PM
  • Thank you very much for the clarification.

    Most of the SaaS vendors don't really tell you that. They just provide you the instructions on creating the claim rules.


    Monday, December 24, 2018 2:24 AM