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.
Related
I am using APIM to expose multiple endpoints from a range of different Azure Functions as operations in the same API. Different operations in this API might have different audiences (aud) in the token based on which function is behind that particular operation.
What might differ though, is that the authorized party (azp) is not always the same. According to the OIDC documentation, this should then also be verified. In some cases, requests originate from a single page application where the token is issued on behalf of a user that signed in. In other cases, the request originates from someone integrating towards my APIs using a principal instead and a client_credentials grant type.
What I want to achieve is to have as simple a policy as possible, and still allow a range of different azp claims for a single aud claim. This is how I'm currently doing this:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/{{tenantId}}/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud" match="all">
<value>{{target-api-clientId}}</value>
</claim>
<claim name="azp" match="any">
<value>{{spa-clientId}}</value>
<value>{{integrator-clientId1}}</value>
<value>{{integrator-clientId2}}</value>
</claim>
</required-claims>
</validate-jwt>
However, this doesn't scale very well and forces me to keep duplicate policies between environments and for each new allowed authorized party I must add a new row in the azp claim section as a well as new named values.
The documentation specifies that there is a separator attribute for the claim element, but as far as I can tell, this only splits the claim in the incoming token on that separator character and I always only have a single aud and azp claim in the incoming tokens.
Is there any way for me to achieve a single API baseline policy, where each operation could set its expected required parameters? Something along these lines:
API base policy
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/{{tenantId}}/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud" match="all">
<value>#((string)context.Variables["aud"])</value>
</claim>
<claim name="azp" match="any">
#((List<string>)context.Variables["azp"])
</claim>
</required-claims>
</validate-jwt>
Operation specific policy
<set-variable name="aud" value="{{allowed-aud-for-this-operation}}" />
<set-variable name="azp" value="{{list-of-allowed-authorized-parties-for-this-operation}}" />
<base />
To further clarify what the infrastructure looks like and where requests might originate from, this might shine some light:
Is there any way to achieve dynamic token evaluation like this? If not, what are my other options? Am I approaching this problem the right way, or should I rethink?
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
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
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.
What do I need
In my application I have a following schema
users (id(PK), username, email(unique), password, etc)
devices (id(PK), device_id, status, user_id)
Relation
user HAS ONE device
The application needs to support basic authentication in two variations.
Variation one: Normal, email as username and password. This approach will be used by the admin console. The admin console just like an webapp.
Variation two: email as username, device id as password. This approach will be used by mobile application. During the authentication process from device, it will pass the device id as password. Since a user will have only device at a time, the authentication process will match the device id and email to identify the user.
What I tried?
I have basically followed symfony tutorial on api key based authentication for the second variation and http-basic for the first. Please find my security.xml below.
Here, I need the firewall setup to pass when any of the underlying authentication mechanism passes. For instance, in case of web authentication, only http-basic will pass, in case of device login only simple-preauth will pass.
security.xml
<srv:container xmlns="... ...">
<config>
<firewall name="resource" pattern="^/" stateless="true">
<http-basic realm="Webservice" />
<simple-preauth authenticator="device_authenticator" />
</firewall>
<provider name="administrators">
<entity class="AppBundle\Entity\User" property="email"/>
</provider>
<provider name="device_id_user_provider" id="device_id_user_provider" />
<encoder class="AppBundle\Entity\User" algorithm="bcrypt" cost="12"/>
</config>
</srv:container>
services.xml
<container xmlns="... ...">
<services>
<service id="device_id_user_provider"
class="AppBundle\Security\DeviceIdUserProvider">
<argument type="service" id="doctrine.orm.entity_manager" />
</service>
<service id="device_authenticator" class="AppBundle\Security\DeviceAuthenticator">
<argument type="service" id="device_id_user_provider" />
</service>
</services>
</container>
My problem
For every request the firewall tries to pass both of the authentication mechanisms. Hence its always responding with 401.
Did I set this up in a wrong way?
Or a firewall MUST pass all of its underlying auth mechanisms?
Or this is happening only because of using preauthentication?
Any recommended approach to achieve this?