Broadcom API Gateway - Validate SAML Token fails with "SAML token validation errors: Unable to parse SAML token: AssertionID missing or empty"
search cancel

Broadcom API Gateway - Validate SAML Token fails with "SAML token validation errors: Unable to parse SAML token: AssertionID missing or empty"

book

Article ID: 229236

calendar_today

Updated On:

Products

CA API Gateway

Issue/Introduction

While trying to validate a non-soap SAML token, the Validate SAML Token assertion throws below error in spite of the presence of AssertionID tag in the inbound SAML token. 

WARNING 2073 com.l7tech.external.assertions.validatenonsoapsaml.server.ServerValidateNonSoapSamlTokenAssertion: 6104: SAML token validation errors: Unable to parse SAML token: AssertionID missing or empty

Here an example of request's body containing the offended SAML token with the included Assertion ID:

<samlp:Response ID="_a4958bfd-e107-4e67-b06d-0d85ade2e76a" Version="2.0" IssueInstant="2013-03-18T07:38:15.144Z" Destination="https://contoso.com/identity/inboundsso.aspx" InResponseTo="id758d0ef385634593a77bdf7e632984b6" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer>
  <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
    ...
  </ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
  </samlp:Status>
  <Assertion ID="_bf9c623d-cc20-407a-9a59-c2d0aee84d12" IssueInstant="2013-03-18T07:38:15.144Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>https://login.microsoftonline.com/82869000-6ad1-48f0-8171-272ed18796e9/</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      ...
    </ds:Signature>
    <Subject>
      <NameID>Uz2Pqz1X7pxe4XLWxV9KJQ+n59d573SepSAkuYKSde8=</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="id758d0ef385634593a77bdf7e632984b6" NotOnOrAfter="2013-03-18T07:43:15.144Z" Recipient="https://contoso.com/identity/inboundsso.aspx" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2013-03-18T07:38:15.128Z" NotOnOrAfter="2013-03-18T08:48:15.128Z">
      <AudienceRestriction>
        <Audience>https://www.contoso.com</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
        <AttributeValue>[email protected]</AttributeValue>
      </Attribute>
      <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
        <AttributeValue>3F2504E0-4F89-11D3-9A0C-0305E82C3301</AttributeValue>
      </Attribute>
      ...
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2013-03-18T07:33:56.000Z" SessionIndex="_bf9c623d-cc20-407a-9a59-c2d0aee84d12">
      <AuthnContext>
        <AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
  </Assertion>
</samlp:Response>

Environment

API Gateway 9.4/10.0+

Cause

Specific tokens (for example from Microsoft Azure AD) may not be generated in the correct format expected by the Evaluate SAML Token assertion, causing attributes not to be parsed during the validation and leading to a failure in the policy process. 

 

Resolution

Under this specific scenario, it is recommended to manually parse the validation's element (Assertion ID) from the request body, then store it in a variable and use the variable (not the request itself) against the Evaluate SAML Token assertion. 

In roder to do so:

  • Add Evaluate Request XPATH assertion before Validate SAML assertion 

  • Double click on the new added assertion and :

- Click on the ADD button (1)

- Give a name to the Sample Message (2)

- Paste the SAML response body in the XML Document box and (VERY IMPORTANT) select/highlight the Assertion ID element (3) that needs to be parsed

- Click OK (4) 

- Assign a Variable Prefix (5) and click OK to save the assertion configuration. Take note of the prefix name as we will use it later when we setup a context variable.

 

  • Add a Set Context Variable assertion, give to it a name (in this example is called assertionid ), set the Data Type as Message, Content-Type as text/xml and set the Expression as ${variable01.element} . The name before ".element" must match with the Variable Prefix name previously used in the Evaluate Request XPath

 

  • Right click on Validate SAML assertion and from the menu, click on Select Target Message

  • Select Other Context Variable and in the empty field, insert the Context Variable created previously.

The final policy logic should look something like below: