SAML Response with Signed Message & Encrypted Assertion

[Akshat Aranya]

Please help on how to process SAML Response with Signed Message & Encrypted Assertion on layer7 api gateway , if anyone has done this a sample piece of code will be helpful.

[Jay MacDonald]

Can you provide more details on what you are trying to do? Is this a SAMLP response to a SAMLP request? I need more clarity around your flow.

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Akshat Aranya]

We are using layer7 as service provider to process the SAMLP response coming from identity provider, the SAMLP response is signed message with encrypted assertion structure below

<samlp:Response Version="2.0" ID="dwdwdwdwdaxdrg#" IssueInstant="2020-07-08T04:02:21.210Z" Destination="URI of SP"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <samlp:Response Version="2.0" ID="dwdwdwdwdaxdrg" IssueInstant="2020-07-08T04:02:21.210Z" Destination="URI of SP"
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml:Issuer
            xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> IDP Entity ID 
        </saml: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="xcxvead#">
                    <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> Digest Value </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue> Signature Value </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate> IDP X509 Certificate </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <samlp:Status>
            <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
        </samlp:Status>
        <saml:EncryptedAssertion
            xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
            <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
                <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                <ds:KeyInfo
                    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                    <xenc:EncryptedKey>
                        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
                        <xenc:CipherData>
                            <xenc:CipherValue>Cipher Value</xenc:CipherValue>
                        </xenc:CipherData>
                    </xenc:EncryptedKey>
                </ds:KeyInfo>
                <xenc:CipherData>
                    <xenc:CipherValue>Encrypted Data</xenc:CipherValue>
                </xenc:CipherData>
            </xenc:EncryptedData>
        </saml:EncryptedAssertion>
    </samlp:Response>

We are trying to find a way to read the encrypted assertion to process at layer7

The key here is also rsa-oaep-mgf1p encrypted, and the assertion is aes-128-cbc 

Please share any suggestions or code examples on how to proceed.

I have tried Non Soap Decrypted element assertion, require encrypted element assertions of layer7 and still not able to process.

The error recieved is "Unable to decrypt elements(s): EncryptedKey includes no KeyInfo element. Exception caught! "

Code logic i have developed till now

[Jay MacDonald]

It looks like the Gateway expects there to be a <dsig:KeyInfo> element in the <xenc:EncryptedKey> element to indicate the key to which it was encrypted. Is it possible to have the provider introduce that to the response?

When I use the (Non-SOAP) Encrypt XML Element assertion, that is what it does, and the documentation for the (Non-SOAP) Decrypt XML Element assertion states "The (Non-SOAP) Decrypt XML Element assertion is intended to decrypt elements that were encrypted using the (Non-SOAP) Encrypt XML Element assertions." Personally, I think that's a bit bogus - the Gateway usually finds private keys automatically when it needs to decrypt something. I'll file a feature request.

For reference, here is the <xenc:EncryptedKey> segment from your sample, and the result of using the (Non-SOAP) Encrypt XML Element assertion for comparison. The only distinction (besides a couple of extra namespace declarations) is the inclusion of the <dsig:KeyInfo> block.:

<xenc:EncryptedData Type="www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="www.w3.org/2001/04/xmlenc#">
    <xenc:EncryptionMethod Algorithm="www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <dsig:KeyInfo xmlns:dsig="www.w3.org/2000/09/xmldsig#">
        <xenc:EncryptedKey>
            <xenc:EncryptionMethod Algorithm="www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
            <xenc:CipherData>
                <xenc:CipherValue>Cipher Value</xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedKey>
    </dsig:KeyInfo>
    <xenc:CipherData>
        <xenc:CipherValue>Encrypted Data</xenc:CipherValue>
    </xenc:CipherData>
</xenc:EncryptedData>​

<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
        <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
            <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
            <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                <dsig:X509Data>
                    <dsig:X509IssuerSerial>
                        <dsig:X509IssuerName>CN=Jay MacDonald,O=Broadcom,L=Vancouver,ST=BC,C=CA</dsig:X509IssuerName>
                        <dsig:X509SerialNumber>1852103851</dsig:X509SerialNumber>
                    </dsig:X509IssuerSerial>
                </dsig:X509Data>
            </dsig:KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue>Njd42UnlZgbEUCnWjz6/HIPuO4Znj7MvWMk7TjEmNz8bRIG5WjuNnhwoBFi6acoYUk4uCX6drAkHN5AwCC3CMFYHotpt8Q67kBeNW5nYa03SzVe/jIXiB5eEO5qofynGd6fwjnZk5Uzxc6kDEQAmUxCKIpaJPmL7eSg9urkHYWc9ovjKaJWJKkOb+pfc+Smr8Wnon2t1Wcwbc8Y0eUG7W+4VtjPCsRwNYr1DtOoA3K37k2Od9bOKmjfS2XGoYTxLgf5JNeGt55V5eMvS2WgJZSJKHyAIie27oN7r17OcYP6f21FJ1/iPe4EqhNW2/SYqfEEGT8SfZGG/v+7f5VQoew==</xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedKey>
    </dsig:KeyInfo>
    <xenc:CipherData>
        <xenc:CipherValue>g2njkUy9bXQIWeGFa1654KCZP8oXxPgEUnJgpQrPcjO9fj5iRvPoTy7eK7AQLgb4nJDowo07Cj5RTERdEikorhatLVUAnOESO7f3BFaSm+wpMUPe8x+D5lcP5r57YUBl</xenc:CipherValue>
    </xenc:CipherData>
</xenc:EncryptedData>​

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Akshat Aranya]

Thanks for the tip, for testing purpose I modified the incoming xml and added the keyinfo and it helped in decryption of the SAML, using the (Non-SOAP) Encrypt XML Element assertion, but i have few questions

1) is there a layer7 asserting to handle the encrypted samlp response
2) shall we use  (Non-SOAP) Encrypt XML Element assertion or some other assertion for decryption

Whats the best option here.

Also I think something is wrong here with the approach i have taken as the output after decryption is not valid samlp:response the saml:EncryptedAssertion shouldn't be there

The output looked like below post decryption

<samlp:Response Destination="SP ACS URL" ID="wpqB2BPydsBJ0Ym9aPRSrViKDou" IssueInstant="2020-07-09T13:07:12.388Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

 <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">IDP Entity ID Here</saml: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="#wpqB2BPydsBJ0Ym9aPRSrViKDou">

 <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> Digest Value here </ds:DigestValue>

 </ds:Reference>

 </ds:SignedInfo>

 <ds:SignatureValue> Signature Value here </ds:SignatureValue>

 <ds:KeyInfo>

 <ds:X509Data>

 <ds:X509Certificate> IDP X509 Cert here </ds:X509Certificate>

 </ds:X509Data>

 </ds:KeyInfo>

 </ds:Signature>

 <samlp:Status>

 <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

 </samlp:Status>

 <saml:EncryptedAssertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

 <saml:Assertion ID="pOi7zswXFkaaGNic3qhfyBOF5H8" IssueInstant="2020-07-09T13:07:12.392Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

 <saml:Issuer>SP Entity ID</saml: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="#pOi7zswXFkaaGNic3qhfyBOF5H8">

 <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> Digest Value here </ds:DigestValue>

 </ds:Reference>

 </ds:SignedInfo>

 <ds:SignatureValue> Signature Value here </ds:SignatureValue>

 <ds:KeyInfo>

 <ds:X509Data>

 <ds:X509Certificate> IDP X509 Cert here </ds:X509Certificate>

 </ds:X509Data>

 </ds:KeyInfo>

 </ds:Signature>

 <saml:Subject>

 <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">NameIDvalue</saml:NameID>

 <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

 <saml:SubjectConfirmationData NotOnOrAfter="2020-07-09T13:12:12.392Z" Recipient="SP ACS URL"/>

 </saml:SubjectConfirmation>

 </saml:Subject>

 <saml:Conditions NotBefore="2020-07-09T13:02:12.392Z" NotOnOrAfter="2020-07-09T13:12:12.392Z">

 <saml:AudienceRestriction>

 <saml:Audience>SP Entity ID</saml:Audience>

 </saml:AudienceRestriction>

 </saml:Conditions>

 <saml:AuthnStatement AuthnInstant="2020-07-09T13:07:12.391Z" SessionIndex="pOi7zswXFkaaGNic3qhfyBOF5H8">

 <saml:AuthnContext>

 <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>

 </saml:AuthnContext>

 </saml:AuthnStatement>

 <saml:AttributeStatement>

 <saml:Attribute Name="ATTR1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

 <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">ATTR1value</saml:AttributeValue>

 </saml:Attribute>

 <saml:Attribute Name="ATTR2" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

 <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">ATTR2value</saml:AttributeValue>

 </saml:Attribute>

 </saml:AttributeStatement>

 </saml:Assertion>

 </saml:EncryptedAssertion>

</samlp:Response>​

------------------------------
Regards
Akshat

[Jay MacDonald]

It's been a while since I have messed with this stuff, so I apologise for the delay. I had to run a bunch of tests to refresh my knowledge.

To answer "1) is there a layer7 asserting to handle the encrypted samlp response?"

No, unfortunately. The "Evaluate SAML Protocol Response" assertion does not work with with an encrypted SAMLP response. You will need to decrypt the assertion component first.

To answer "2) shall we use (Non-SOAP) Encrypt XML Element assertion or some other assertion for decryption?"

Yes.

In a SAMLP response, the SAML assertion statement, which follows the Status element, can either be plaintext or encrypted. If it is plaintext then you will simply see the <saml:Assertion> element. If it is encrypted you will see the <saml:EncryptedAssertion> element with the <xenc:EncryptedData) in it. The Evaluate SAML Protocol Response assertion requires it to be in plaintext (per question #1).

If it is plaintext then we can go straight to using the Evaluate SAML Protocol Response assertion to validate its contents, or you can use XPath statements to extract the components of it for a more hands-on approach to the validation.

If it is encrypted then you will need to decrypt the <xenc:EncryptedData> element, as you have done, using the (Non-SOAP) Decrypt XML Element assertion. However, this leaves the Assertion still as a child to the <saml:EncryptedAssertion> element, which is a problem. To fix this you need to use an XSLT stylesheet to replace <saml:EncryptedAssertion> with its child.

I have attached a sample policy to illustrate this. It creates a simple attribute statement SAML assertion, then forks to illustrate the two use cases (plaintext vs encrypted). You will need to reset the keys used in the policy when you import it, but this should help you understand what I am talking about. Just create a test endpoint on the gateway and import this policy into it then hit it with a browser or curl with username and password from the internal identity provider. You can change the ${useCase} value to test the different use cases (plaintext vs encrypted), and enable/disable assertions to experiment with the various possibilities.

Note that if validating the signature on the SAMLP response is a requirement it MUST be done before anything else, since the <saml:EncryptedAssertion> element is part of the signed content and any transforms of the SAMLP response will break the signature. Also, if the SAMLP provider can't include the KeyInfo details you can transform those into the document AFTER the signature has been validated.

Cheers!

JayMac

​

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

Attachment(s)

SAMLP-Policy.xml   17 KB 1 version

[Akshat Aranya]

Thanks a lot Jay for sorting all the queries, it was  really helpful, really appreciate your help here

Regards,
Akshat