Gateway : OAuth + SAML Browser POST - Issue with AuthnRequest (inside SOAP Element)

[Legacy User]

Use-case:

 

Want to implement OAuth Authorization Code Grant type.

1. The Authorization Server is Layer 7. OAuth Client hits /authorize hosted by Layer 7.
2. The Layer 7 should send a SP-initiated SAML WebSSO Request POST Binding to Ping Idp
3. Login Page thrown by Ping
4. Ping IDP returns back SAML Assertion
5. Layer 7 returns auth code.
6. Client hits /token with auth code
7. Layer 7 returns access token
8. Client access API + Access Token

 

Issue:

 

1)      There is no pre-baked end to end policy for Web-SSO. This will make difficulty to maintain and we can easily deviate from standards.

2)      Downloaded some policy from community which had a sample websso service provider.

1. Here they create a SAMLRequest, where it asks for SOAP version.
2. The <AuthnRequest> is wrapped with in SOAP message, as per the standard it should go as the parent body.
3. I cannot extract <AuthnReqeuest/> from the wrapped SOAP message, as this will make my the signature wrong.

3)      Please find below the snapshot of “SAML Protocol Request Wizard”

 

 

4)      The SAML Request produced :

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

   <soapenv:Header/>

   <soapenv:Body>

   <samlp2:AuthnRequest Destination="https://ping.widaas.com:9031/idp/SSO.saml2" ID="samlp2-a31e3e6db54a86453ed37dcef3eb4af4" IssueInstant="2019-04-09T19:50:33.241+05:30" Version="2.0" xmlns:ac="urn:oasis:names:tc:SAML:2.0:ac" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp2="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://apigw.widaas.com:8443/saml2/websso/layer7sp</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/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#samlp2-a31e3e6db54a86453ed37dcef3eb4af4"><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>6O/bfhhf4x4EtCfssInpd0sq53k=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ReLf0vqXu5jureQSXIKqHQ1atMiRI7/XOOSP97boDnVGdsxrylnUibJJMABIqQLViRJUylEb/554wNbhqaojH6npk5pP8sylJR/nO2tKCJvJlDpvbL5drkkDLKpolGnPctE/FPEycaWtxYIwH1EEAC29qExqrCOkKIQTl0sD5fj0fiAAQXWGjratpGHlUYew8wv06/1+WQAw4r6xjPYGEY5MtrQwJNTA/MyDu1YcxPRn5ch6yt1ZSpix1PcL6IkcZGVhJMByF/vCA0c+CjxiGV6+ii/7/GfUywYGcgqoZI+tl+4gkluicwX9FUNSR90WtPG0oOWi+G14IpfO1uyxQA==</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><X509Data><X509SubjectName>CN=apigw.widaas.com</X509SubjectName><X509Certificate>MIIC+jCCAeKgAwIBAgIITnVje0OSzl8wDQYJKoZIhvcNAQEMBQAwGzEZMBcGA1UEAxMQYXBpZ3cud2lkYWFzLmNvbTAeFw0xOTAzMTMwNTExMDhaFw0yOTAzMTAwNTExMDhaMBsxGTAXBgNVBAMTEGFwaWd3LndpZGFhcy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUCTgCcFEXwkzfZ/9fstDvTuF64tIlyiMx6W+PrBqS16jPpoj3x497+5lwDSxHu3ykjBZCeOclbHUb2bP5ILjRaYjZrJr4ji1fOl97N0xFcHb0Y3Alq2cxDkTubILgrVPi6Izk/bX6E+9ErwtbfFod31Ll5KQp9Dq4srKzAKZpVbqMcDneysT6xDOzkwapkvtFTymHAK7Ynm8jo23skcvPVYViSpN/wERuKl78gGtriTK35uUg+Er3KDNh1Pyo3HJPE7osOyDJKVulMVAw1tLknlJCcSgbx3Pu8Y5Jdlr0iAKxjmMvfT++z2neQH7mJQg+tE+nxDTbXAkC3qhCzzwJAgMBAAGjQjBAMB0GA1UdDgQWBBT+ZzjVcByomPqo4C+Giu+5b3SSGzAfBgNVHSMEGDAWgBT+ZzjVcByomPqo4C+Giu+5b3SSGzANBgkqhkiG9w0BAQwFAAOCAQEARMnMQ4I9bi0TPrPBjCKYvn7dW+ZVqzXJeWCQGXn5N++qql+nF21ExVkAHHXkoLq8N1KYBVyOGviwdUoOwCFlEhFW60x9UGp9NmHmNaLfgkfTxqkGcN4fTUTCzCqgRsxJwMFnRqhPRaitVxuMmWLEm7hZOVeXxzJ5IeVGFAtHcGpgSihiN6gC+l/ghlftcXmYDEpCqpKMC6XjCP/jQknUCACsRtf6/UUUUL+vHWy72WkN01ysNwlYay/3I1WqJ3E1WFgNkO/byQRRZltPAgfHMwcFgRUs6wuekH0eLZIPtLDIpamt5VYDh2Q/AkANezjLFOyIHkjCGxt0pF4o1A42gQ==</X509Certificate></X509Data></KeyInfo></ds:Signature><saml2:Subject><saml2:NameID xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData NotBefore="2019-04-09T19:50:32.000+05:30" NotOnOrAfter="2019-04-09T20:50:33.242+05:30" Recipient="https://apigw.widaas.com:8443/saml2/websso/layer7sp"/></saml2:SubjectConfirmation></saml2:Subject></samlp2:AuthnRequest></soapenv:Body>

</soapenv:Envelope>

[Jennard Dy]

Hi, I'm a Broadcom software engineer working on the CA API Gateway.

 

Regarding the <AuthnRequest>, you want to put it in a location other than inside the SOAP <Body> element? If this is the case, you cannot use the Build SAML Protocol Request assertion by itself since it will automatically put the <AuthnRequest> in the <Body>, but you can use it in addition to other assertions to build your own request.

 

Steps:

1. Use Build SAML Protocol Request to create the <AuthnRequest>. In the last step, leave the Sign Request check box unchecked. You need an unsigned <AuthnRequest> in order to be able to move it around.

2. You can use Evaluate Request XPath assertion (or if needed, Evaluate Regular Expression assertion) to get the unsigned <AuthnRequest> element and store it in a context variable

3. You can now build your own request via Set Context Variable assertion using the stored context variable in step 2.

4. Sign the request using the Sign Element assertion

 

This is a simplified step-by-step (you might have more complex requirements), but the point is you need unsigned <AuthnRequest> in order be able to put it anywhere in the request. After the request is built, then you can sign the request as before, and you should end up with a signed request with <AuthnRequest> element not inside <Body> element.

 

Hopefully this helps. Thank you very much.

Regards,

Jennard Dy

[Elizabeth Currier]

Thank you for the important assistance this thread gives us in our quest to complete a SAML federation between our own Pingfederate IdP service and L7 API Gateway acting as an SP, accepting SAML assertions. This thread appears to be an exact match for our use case. The above recommended steps are clear, at the highest level, but we had a couple of points of further enquiry, we would greatly appreciate anything you could share with us on them:

 

1. The use case and the BC engineer's response appears to vindicate our believe we can engage in an SP initiates SAML partnership between Pingidentity Pingfederate and L7 API Gateway operating as an SP. L7 API will then be able to accept SAML assertion tokens for processing, and combining with our OAuth2 based authorization flow (we'll need to accompany the assertion with a SessionID). Is that a fair comment?
2. Based on the above, we will be sticking to saml2 based assertion, POST binding (/ACS/saml2) – as opposed to Artifact based (ARS/ssaml2)that the SAML schema is of type soapenv.  That correct?

• Re: step 3, above do you have any helpful examples of a request built with a Set Context Variable? This would help us when building our own.

 

Our AuthNReq should end up looking like this

 

Authentication Request (AuthNReq)

 

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                    Version="2.0"

                    ID="vTV5xBOkGjzbEZBzuS.Bzl5GkgV"

                    IssueInstant="2020-10-07T18:35:52.171Z"

                    >

    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">saml2grnp.eagleaccess.com</saml:Issuer>

    <samlp:NameIDPolicy AllowCreate="true" />

</samlp:AuthnRequest>

 

This compares with an AuthNReq for our L7 API Gateway service:

 

URL: https://eaapimgr-dmzlb.eagleaccess.com/saml2/websso/serviceprovider

 

<error>

                javax.servlet.ServletException: javax.servlet.ServletException: org.sourceid.saml20.bindings.BindingException: Inbound message contains insufficient information to determine the identity of the partner. InMessageContext

</error>

 

<fragment>

XML: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <soapenv:Header/>

  <soapenv:Body>

    <samlp2:AuthnRequest Destination="https://saml2pghn.eagleaccess.com/idp/SSO.saml2" ID="samlp2-205cea8d61b96345f4f8c51903816135" IssueInstant="2020-10-07T12:08:34.380-04:00" Version="2.0" xmlns:ac="urn:oasis:names:tc:SAML:2.0:ac" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp2="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

      <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" NameQualifier="eaapimgr-dmzlb.eagleaccess.com">CN=*.eagleaccess.com, OU=Eagle ACCESS, O=Eagle Investment Systems LLC, L=Wellesley, ST=Massachusetts, C=US</saml2:Issuer>

      <ds:Signature>

</fragment>

 

The error we are receiving on the AuthNReq from Ping org.sourceid.saml20.bindings.BindingException: Inbound message contains insufficient information to determine the identity of the partner clearly points to the exact, same Name formatting issue you are referring to.