ADFS 3.0 versus PHP SimpleSAML
We stumbled upon an issue at a customer last month. When setting up a federative trust between ADFS and SimpleSAML we received multiple errors:
Exception during login: SimpleSAML_Error_Exception: Could not find the metadata of an IdP with entity ID '<a href="http://adfs.customer.nl/adfs/services/trust" data-mce-href="http://adfs.customer.nl/adfs/services/trust">http://adfs.customer.nl/adfs/services/trust</a>' SimpleSAML_Error_Exception: Could not find the metadata of an IdP with entity ID 'tenant2.test.com' in sspmod_saml_Auth_Source_SP->getIdPMetadata() (line 134 of /var/www/vendor/simplesamlphp/simplesamlphp/modules/saml/lib/Auth/Source/SP.php)
SimpleSAML_Error_Error: UNHANDLEDEXCEPTION Backtrace: 0 /var/www/html/igt_s3k/web/simplesamlphp/www/module.php:179 (N/A) Caused by: sspmod_saml_Error: Requester/InvalidNameIDPolicy
In the Event Viewer on the ADFS server we saw many 321 and 364 errors.
The SAML authentication request had a NameID Policy that could not be satisfied. Requestor: https://sendingdomain.com/saml/module.php/saml/sp/metadata.php/tenant Name identifier format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SPNameQualifier Exception details: MSIS7070: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SPNameQualifier: . Actual NameID properties: null. This request failed. User Action Use the AD FS Management snap-in to configure the configuration that emits the required name identifier. Encountered error during federation passive request. Additional Data Protocol Name: Saml Relying Party: https://sendingdomain.com/saml/module.php/saml/sp/metadata.php/tenant details: Microsoft.IdentityServer.Protocols.Saml.InvalidNameIdPolicyException: MSIS7070: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SPNameQualifier: . Actual NameID properties: null. at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested) at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String& samlpSessionState, String& samlpAuthenticationProvider) at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired) at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken) at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context) at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler) at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
As you can see in the URN urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, this is not in line with ADFS 3 standards. So, we must create a Transform Claim rule to handle this request. We can do this in the following way:
Go to AD FS Management Console, AD FS, Trust Relationships, Relying Party Trusts and select the correct paty. Right click the selected party and choose Edit Claim Rules…
Add two rules.
The first will be Send LDAP Attributes as Claims, and make sure you set the E-Mail-Adresses as LDAP Attribute (remember the URN urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress the relying party will use the email address as the uid).
The second one is a Transform an Incoming Claim rule. This will Transform the UPN to the correct nameidentifier. When you click the View Rule Language… button you will see the following schema:
c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”]
=> issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[“http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format”] = “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”);
When you have added both of these claim rules you will see the following rule set, and users will successfully connect via ADFS.
Greetings,
Daniel Nikolic
Is interested in everything connected to technology. Has a passion for cloud, virtualization and software development. Always finds appropriate IT solutions for customers that match their needs strategically, technically and financially.
Core qualities
Quick thinker, result driven, ambitious, customer-friendly, enthusiastic
Hobbies
Running, listening to music, good food and doing fun things with family
Job description
CTO PepperByte, LoadGen, and BlueParq
Leave a Reply
Want to join the discussion?Feel free to contribute!