Azure B2C - SAML - The service provider is not a valid audience of the assertion - azure-ad-b2c

I set up a SAML Provider for Azure B2C (Single Sign On). The IDP is happy and sends a SAML Assertion back, but Azure B2C complains.
It looks like Azure B2C cannot process the SAML Answer. The Error Message extracted via AppInsights is simple "The service provider is not a valid audience of the assertion".
The URLs seem to fit, but im not sure if the AudienceRestriction should point to the base policy or maybe the sign-in policy, as teh metadata can only be accessed via the SIGN-UP Policy as part of the URL and not the BASE:
"https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_SIGNUP_SIGNIN/samlp/metadata?idptp={IDP-NAME}-SAML2"
Configuration (updated according to the comments of this question).
Configuration
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
ID="https://{IDP-URL}/saml/2.0/idp/"
entityID="https://{IDP-URL}/saml/2.0/idp/"
validUntil="2099-12-31T23:59:59Z">
<SPSSODescriptor
AuthnRequestsSigned="false"
WantAssertionsSigned="false"
ResponsesSigned="false"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<AssertionConsumerService
index="0"
isDefault="true"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
</SPSSODescriptor>
<IDPSSODescriptor
WantAuthnRequestsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://{IDP-URL}/saml/2.0/idp/" />
</IDPSSODescriptor>
</EntityDescriptor>
SAML Response
<saml2p:Response Destination="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer"
ID="Response_6793aae6a9cc629a6be69a270731961695dad50e"
InResponseTo="_719e3407-dbad-4761-8e8a-7e7272b2a67b"
IssueInstant="2022-08-17T08:34:29.112Z"
Version="2.0"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://{IDP-URL}/saml/2.0/idp/</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
<saml2:Assertion ID="Assertion_16dc5f9b7c67ed241c79436c20296a2fd514ea87"
IssueInstant="2022-08-17T08:34:29.111Z"
Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
<saml2:Issuer>https://{IDP-URL}/saml/2.0/idp/</saml2: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="#Assertion_16dc5f9b7c67ed241c79436c20296a2fd514ea87">
<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#">
<ec:InclusiveNamespaces PrefixList="xs"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>/4OAX07/scGvFyDCT3BBzlHJQ7q65Ak0uGlTvE0z904=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>{removed}</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>{removed}</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">71747</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_719e3407-dbad-4761-8e8a-7e7272b2a67b"
NotOnOrAfter="2022-08-17T08:34:39.112Z"
Recipient="https://{my-tenant-name}/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer"
/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2022-08-17T08:34:29.111Z"
NotOnOrAfter="2022-08-17T08:34:59.111Z"
>
<saml2:AudienceRestriction>
<saml2:Audience>https://{my-tenant-name}/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2022-08-17T08:34:29.111Z"
SessionNotOnOrAfter="2022-08-17T10:34:29.111Z"
>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
My SAML METADATA
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" ID="_7865bef4-f0d2-4062-9e58-a145e1beb91f" entityID="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_7865bef4-f0d2-4062-9e58-a145e1beb91f">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="saml samlp xenc xs"/>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>bSqD69uUzX0swY6hAKkzLEaWJeMyV2UIoyFBTxLhHi0=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>AiyK11or3hAGSnHADidHKp2XCcH0amBaU8xA6xQrxgKNZBqaKFF0rdbiRdVp4YFbqlQeCruYAEbT1JnAAwRyKLn6IZOJIP7iA3PeSr8bguus58+LGmb30YsYcbpAMxLjhQbmAu1t25v4huaOViZQwNAafkdjKAyhJRa7P8ihEBbl4CUQjYJ0eIASxWZuD6j1tg4afMv9GH809lFGl7KRER8oUp9P6VF5xdJbavpX623eRZRAeqV++CBXKTrFUnMOHrp1eI68IaobKOx/xkN59FX7SabdqpIVE+L9rnPtYYwG0LLpqmAOaSZEhmGKp2y27OA1ZxJZittwFMTmWmtoqA==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>{removed}</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>{removed}</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_signup_signin/samlp/sso/logout" ResponseLocation="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_signup_signin/samlp/sso/logout/response"/>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://{my-tenant-name}.b2clogin.com/{my-tenant-name}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>
</EntityDescriptor>

Please check below points:
Subject contains a NameID element, which represents the authenticated user. The NameID value is a targeted identifier that is directed only to the service provider that is the audience for the token. It is persistent - it can be revoked, but is never reassigned.
nameidpolicys element requests a particular name ID format in the response
ex:
<NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
The Format attribute can have only one of the following values;
Persistent, emailAddress, unspecified, transient
For urn:oasis:names:tc:SAML:2.0:nameid-format:persistent : Azure
Active Directory issues the NameID claim as a pairwise identifier.
For urn:oasis:names:tc:SAML:2.0:nameid-format:transient: Azure Active
Directory issues the NameID claim as a randomly generated value that
is unique to the current SSO operation. This means that the value is
temporary and cannot be used to identify the authenticating user.
But as seen from the configuration that you provided , it seems to be transient:
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
And response has it persistent. Please check with that.
Audience in audience restriction contains a URI that identifies an intended audience. Azure AD sets the value of this element to the value of Issuer element of the AuthnRequest that initiated the sign- on. Please check and Configure Azure Active Directory B2C as a SAML IdP to your applications | Microsoft Docs
Conditions element specifies conditions that define the acceptable use of SAML assertions.Please check the allowed audience is valid.
References:
using-azure-ad-b2c-as-a-saml-idp-with-the-sp-initiated-flow(medium.com)
audience restriction and proxy restriction-saml-core-2.0-os.pdf

Related

OpenAM giving "Error processing AuthnRequest. Unable to generate NameID value." error

I am using OpenAM as an in-house IDP service. The flow I am using is IDP initiated where-in I am using the below link:
http://127.0.0.1:8080/openam/idpssoinit?metaAlias=%2Fidp&spEntityID=https%3A%2F%2Fmcrmpssso.maxlifeinsurance.com%2Fybl%2Fsps%2Fsamlybl%2Fsaml20
The SP metadata.xml is as below:
<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2020-06-06T05:29:49Z" cacheDuration="PT604800S" entityID="https://mcrmpssso.maxlifeinsurance.com/ybl/sps/samlybl/saml20">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<!--md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIDGDCCAgCgAwIBAgIIfnbJwHIEE14wDQYJKoZIhvcNAQELBQAwKjELMAkGA1UEBhMCdXMxDDAKBgNVBAoTA2libTENMAsGA1UEAxMEaXNhbTAeFw0xODA2MDYwNDU1MTJaFw0yODA2MDQwNDU1MTJaMCoxCzAJBgNVBAYTAnVzMQwwCgYDVQQKEwNpYm0xDTALBgNVBAMTBGlzYW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD7l4RiOOWVv5OsqZwIuypmiX7Zvpxu9FciKKUtqnvTORz957ht+Rn5irMAO6RFyV3Ukk4xZICTegf1Fqfih3/zYUeGpTWb/JqU3ihBHIqAx57dffD/I3q2FZJ6sWua00s0Sj71EpqnTWdFQ2c19pERsV9an17wipuJyak3Rb9utuoYqoFH46Rlpo1Aiaz3wCcfGhN/bZKuxVggVmdqUIx7pI6DrfXj5wBe2RD75gESksTqfjW8w49rGLCfchrVmuFRFM4fe2FW8idcGB/uHQ+AWX3E0pBspNkd/a0KJu/EnI/ZjVN7RQ1+xIqjoM8MtyJRKW93L64BDm/tCj/et0TAgMBAAGjQjBAMB0GA1UdDgQWBBQpC5fyHKU7z+BbO6P5UdKOVCJYTTAfBgNVHSMEGDAWgBQpC5fyHKU7z+BbO6P5UdKOVCJYTTANBgkqhkiG9w0BAQsFAAOCAQEAfdjAQQ1kJTZBdw0ckGBjsteEID0I9qbt4R5vzyeGGjuqlQ0lJww8pYizH8XbfZftlDO10gwrx60fbCUDE0GPDDOAO6p/gcXiFDvsS8NIn3VeyPXtPmYZ8O2/e0LeQ5kWf3p2ZU7ZCIQ+fo9bh5Ve9Amj+Jel4SSL0U+wQQDAfW1+oCqSaXlui2XVH2Tlv+yJBRvk+KRZz3gk9h53f4cRwafp/GH4PDeST/leed1zMXnj/uJqazK+2Q2Wo+LRKuIM4CtkffSzZ4sqn0Uu3VHtjs0ZWY6bUG6pDVs9u3KhX38hzzqy7wgtzdf1o0ai1KPPNOvD1HxYVe7t3yqyeRJZgw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIDGDCCAgCgAwIBAgIIfnbJwHIEE14wDQYJKoZIhvcNAQELBQAwKjELMAkGA1UEBhMCdXMxDDAKBgNVBAoTA2libTENMAsGA1UEAxMEaXNhbTAeFw0xODA2MDYwNDU1MTJaFw0yODA2MDQwNDU1MTJaMCoxCzAJBgNVBAYTAnVzMQwwCgYDVQQKEwNpYm0xDTALBgNVBAMTBGlzYW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD7l4RiOOWVv5OsqZwIuypmiX7Zvpxu9FciKKUtqnvTORz957ht+Rn5irMAO6RFyV3Ukk4xZICTegf1Fqfih3/zYUeGpTWb/JqU3ihBHIqAx57dffD/I3q2FZJ6sWua00s0Sj71EpqnTWdFQ2c19pERsV9an17wipuJyak3Rb9utuoYqoFH46Rlpo1Aiaz3wCcfGhN/bZKuxVggVmdqUIx7pI6DrfXj5wBe2RD75gESksTqfjW8w49rGLCfchrVmuFRFM4fe2FW8idcGB/uHQ+AWX3E0pBspNkd/a0KJu/EnI/ZjVN7RQ1+xIqjoM8MtyJRKW93L64BDm/tCj/et0TAgMBAAGjQjBAMB0GA1UdDgQWBBQpC5fyHKU7z+BbO6P5UdKOVCJYTTAfBgNVHSMEGDAWgBQpC5fyHKU7z+BbO6P5UdKOVCJYTTANBgkqhkiG9w0BAQsFAAOCAQEAfdjAQQ1kJTZBdw0ckGBjsteEID0I9qbt4R5vzyeGGjuqlQ0lJww8pYizH8XbfZftlDO10gwrx60fbCUDE0GPDDOAO6p/gcXiFDvsS8NIn3VeyPXtPmYZ8O2/e0LeQ5kWf3p2ZU7ZCIQ+fo9bh5Ve9Amj+Jel4SSL0U+wQQDAfW1+oCqSaXlui2XVH2Tlv+yJBRvk+KRZz3gk9h53f4cRwafp/GH4PDeST/leed1zMXnj/uJqazK+2Q2Wo+LRKuIM4CtkffSzZ4sqn0Uu3VHtjs0ZWY6bUG6pDVs9u3KhX38hzzqy7wgtzdf1o0ai1KPPNOvD1HxYVe7t3yqyeRJZgw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
</md:KeyDescriptor-->
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mcrmpssso.maxlifeinsurance.com/ybl/sps/samlybl/saml20/login" index="1"/>
<!--md:Organization>
<md:OrganizationName xml:lang="en">MLIC</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en">MLIC</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en"/>
</md:Organization-->
</md:SPSSODescriptor>
</md:EntityDescriptor>
IDP configured NameID format and value:
SP configured NameID format:
OpenAM's stack-trace:
libSAML2:04/05/2020 08:05:57:847 PM UTC: Thread[http-nio-8080-exec-5,5,main]: TransactionId[bf5ec287-6206-4f48-bba0-f968efd3146f-32206]
ERROR: Error processing request
com.sun.identity.saml2.common.SAML2Exception: Unable to generate NameID value.
at com.sun.identity.saml2.plugins.DefaultIDPAccountMapper.getNameID(DefaultIDPAccountMapper.java:114)
at com.sun.identity.saml2.profile.IDPSSOUtil.getSubject(IDPSSOUtil.java:1618)
at com.sun.identity.saml2.profile.IDPSSOUtil.getAssertion(IDPSSOUtil.java:1009)
...
I am stuck at this issue since several hours. Kindly help.
You need to check if on the configured user data store has an user subject identity attribute 'uid' configured (see NameID Value Map screenshot) and you need to ensure a value is set for the user performing the IdP-initated SSO flow. For testing purpose, you may explicitly specify the NameID format to be used by adding request parameter NameIDFormat=urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

B2C App registration with custom SAML policy - configuring claims

I created some custom policy for our SAML applications in Azure b2c.
Now I want to edit the claims sent by azure b2c to application in SAMLResponse.
I added the claims in the trustframwworkbase:
<ClaimType Id="TESTFELDSTRING">
<DisplayName>TESTFELDSTRING</DisplayName>
<DataType>string</DataType>
<DefaultPartnerClaimTypes>
<Protocol Name="OpenIdConnect" PartnerClaimType="TESTFELDSTRING" />
<Protocol Name="SAML2" PartnerClaimType="TESTFELDSTRING" />
</DefaultPartnerClaimTypes>
<UserHelpText>Your TESTFELDSTRING name.</UserHelpText>
<UserInputType>TextBox</UserInputType>
</ClaimType>
And I changed my custom policy and added some new outputclaim there:
<OutputClaim ClaimTypeReferenceId="TESTFELDSTRING" />
But the claim is still missing in my SAML responses.
I have one application which expects some information as SAML Claim and I do not see how to transmit it.
On the "normal Azure AD" I will be able to configure the claims per app. So one app is sending other claims than another app. How to do this in azure b2c?
I tried to add the claim inside the manifest of my app registration with:
"optionalClaims": {
"saml2Token": [
{
"name": "TESTFELDSTRING",
"source": null,
"essential": false,
"additionalProperties": []
}
]
}
But this is not working too.
My transmitted attributes are:
<saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
FriendlyName="Display Name"
>
<saml:AttributeValue xsi:type="xs:string">XXX</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
FriendlyName="Given Name"
>
<saml:AttributeValue xsi:type="xs:string">XXX</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
FriendlyName="Surname"
>
<saml:AttributeValue xsi:type="xs:string">XXX</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
FriendlyName="Email Address"
>
<saml:AttributeValue xsi:type="xs:string">XXX#XXX.XXX</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="objectId"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
FriendlyName="User's Object ID"
>
<saml:AttributeValue xsi:type="xs:string">xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
Anyone a suggestion?
Did you follow this sample?
Did you add the new claims as output claims in the Technical profile?
Did you also add the new claims as output claims in the <RelyingParty> section?

JWT Validation policy suddently not valid when changed to a different audience with Azure API Management

I have a strange problem changing the value of audience element below for JWT validation within APIM, ref link below
https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#ValidateJWT
1 new link:
https://new.onelogin.com/oidc/token
I only changed the value of audience element from the old version in 2. But I get the validation error below from APIM portal when I tried to save the policy:
The element 'validate-jwt' has invalid child element 'openid-config'. List of possible elements expected: 'required-claims'.
Please note that the old version in 2 doesn’t need the 'required-claims' element.
client_id=new xxx
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Error: expired token or invalid token" require-expiration-time="true" require-scheme="Bearer" require-signed-tokens="true">
<audiences>
<audience>new xxx</audience>
</audiences>
<issuers>
<issuer>https://openid-connect-eu.onelogin.com/oidc</issuer>
</issuers>
<openid-config url="https://openid-connect-eu.onelogin.com/oidc/.well-known/openid-configuration" />
</validate-jwt>
2 The old url and jwt validation, and it works.
https://old.onelogin.com/oidc/token
client_id=old xxx
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Error: expired token or invalid token" require-expiration-time="true" require-scheme="Bearer" require-signed-tokens="true">
<audiences>
<audience>old xxx</audience>
</audiences>
<issuers>
<issuer>https://openid-connect-eu.onelogin.com/oidc</issuer>
</issuers>
<openid-config url="https://openid-connect-eu.onelogin.com/oidc/.well-known/openid-configuration" />
</validate-jwt>
Any idea?
Updates:
Now even the original policy that was working has the issue even nothing has been changed:
The element 'validate-jwt' has invalid child element 'openid-config'. List of possible elements expected: 'required-claims'.
You need to move the openid-configup in the xml and keep it just under validate-jwtopening tag. Please see below:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized" require-expiration-time="true" require-scheme="Bearer" require-signed-tokens="true">
<openid-config url="" />
<issuer-signing-keys>
<key>Base64 Encoded Key</key>
</issuer-signing-keys>
<audiences>
<audience></audience>
</audiences>
<issuers>
<issuer></issuer>
</issuers>
</validate-jwt>

Uses of two certificates and one signature

I am currently working on a SSO feature for a client.
Our application, if there is a need, will authenticate using the SSO feature on startup, and abort if it fails.
I have read many explanations and seen many examples online.
The thing that I don't understand at all is the certificates. Specifically, there seems to be two (different?) certificates used in the operation. One of them is stored on my side as a constant, and the other is sent in the SAML Response in the Signature Element like this:
<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/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#id-2710abae3b0457ad0c241eac043769ae78c83189">
<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/2000/09/xmldsig#sha1" />
<ds:DigestValue>???</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#id-266b413f5282d3da62de3963e5e25cb0782e1a05">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>???</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>???</ds:SignatureValue>
<ds:KeyInfo Id="id-266b413f5282d3da62de3963e5e25cb0782e1a05">
<ds:X509Data>
<ds:X509Certificate>???</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
The fields marked as "???" have not been given to me by the client in the sample response.
As for the other certificate, a good example of it would be here: https://github.com/onelogin/dotnet-saml in "App_Code/AccountSettings.cs".
Furthermore, there is also a signature in the XML, and two "DigestValue" fields that seem to also contain Base64 data in other online examples.
So my question is: Is the local certificate the same as the xml one, and if not, how exactly are they related, and are the signature and DigestValues relevant in that relationship?
As for context, I am trying to test my SSO feature, and everything seems to work except for the certificate, which I can't figure out how to test without real values. Can this be faked? SignedXml.CheckSignature always seems to return false no matter what I put in the XML, even "real" examples (found online).
SAML is based on a circle of Trust.
IdPs trust on SPs and SPs trust on IdPs.
The way that "trust" is implemented is that IdPs need to register SPs metadata (entityID, endpoints and public certs for validate signature and encrypt), and in the same way SPs needs to register IdPs metadata.
Based on your message, it seems you are implementing an SP, so the first step is to register on the SP the IdP metadata, once done, at the SP you will have stored IdP Entity ID, its endpoints as well as the public certificate of the IdP.
That certificate MUST match the ds:X509Certificate value of the Signature included on the SAMLResponse sent by the IdP to the SP during the SSO process.

Office 365 Work with an External SAML Identity gives error: 800478A1

I have configured Azure AD and federated the domain.
I have followed the MSDN guide on using a SAML 2.0 IdP to implement SSO and this blog.
I could successfully redirect to my custom IdP page. The IDP sends a SAML token to "login.microsoftonline.com/login.srf". But it gives an error with code 800478A1.
Please let me know what went wrong. I have copied the SAML response below for reference.
<saml2p:Response
Destination="https://login.microsoftonline.com/login.srf"
ID="id66864f3b430546b1a10e488579ea0ba1"
Version="2.0"
IssueInstant="2016-05-13T01:53:56Z"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:52071/</saml2:Issuer>
<saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="_a1efef91-62e4-4ff5-93c1-9b456603f5d4" IssueInstant="2016-05-13T01:53:56Z">
<saml2:Issuer>http://localhost:52071/Metadata</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">johndoe#example.com</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:Oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData NotOnOrAfter="2016-05-13T02:13:56Z" Recipient="https://login.microsoftonline.com/login.srf" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144"/></saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2016-05-13T01:55:56Z" NotOnOrAfter="2016-05-13T02:15:56Z">
<saml2:AudienceRestriction>
<saml2:Audience>urn:federation:MicrosoftOnline</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AttributeStatement>
<saml2:Attribute Name="IDPEmail">
<saml2:AttributeValue>johndoe#example.com</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
<saml2:AuthnStatement AuthnInstant="2016-05-13T01:53:56Z" SessionIndex="42">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#id66864f3b430546b1a10e488579ea0ba1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>ynB0J1UwKJ9396uOkbMajyi2k8s=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>*** redacted ***</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>*** redacted ***</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</saml2:Assertion>
Actually it seems you are passing user's email in NameID in subject field. Is it possible that your IDP send immutable iD or objectguid in sam response in NAmeID field.

Resources