Null pointer exception in SAML validation.

Hi Team, @dino chiesa

We are trying out SAML Assertion validation in Apigee. We are giving the SAML policy as mentioned in the docs with our Truststore :

 

<ValidateSAMLAssertion name="SAML" ignoreContentType="false">
 
<Source name="request">
   
<Namespaces>
     
<Namespace prefix='soap'>http://schemas.xmlsoap.org/soap/envelope/</Namespace>
     
<Namespace prefix='wsse'>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</Namespace>
     
<Namespace prefix='saml'>urn:oasis:names:tc:SAML:2.0:assertion</Namespace>
<Namespace prefix='samlp'>urn:oasis:names:tc:SAML:2.0:protocol<Namespace>
   
</Namespaces>
   
<XPath>/soap:Envelope/soap:Header/wsse:Security/saml:Assertion</XPath>
 
</Source>
 
<TrustStore>TrustStoreName</TrustStore>
 
<RemoveAssertion>false</RemoveAssertion>
</ValidateSAMLAssertion>

While executing, we are getting an error like "NullPointerException". can you please suggest on what can be done. 

 

 

Also in the case of an encrypted SAML token, we are giving the xpath reference as : 

<XPath>/samlp:Response/saml:EncryptedAssertion</XPath>

 

But we are getting an error "unable to resolve xpath /samlp:Response/saml:EncryptedAssertion". Please help to resolve this. 

Solved Solved
0 2 224
2 ACCEPTED SOLUTIONS

Yes, I can help I think. At least I can help a little. 

First, the XPath element has been supplanted by two new elements,  AssertionXPath and SignedElementXPath. They should be used like this: 

 

 

<ValidateSAMLAssertion ignoreContentType="false" name="Validate-SAML-Assertion-1">

    <Source name="request">
        <Namespaces>
            ...
        </Namespaces>

        <!--<XPath>/samlp:Response/saml:Assertion</XPath>-->
        <AssertionXPath>/samlp:Response/saml:Assertion</AssertionXPath>
        <SignedElementXPath>/samlp:Response</SignedElementXPath>
    </Source>
    ...
</ValidateSAMLAssertion>

 

 

You should no longer use the sole XPath element in your ValidateSAMLAssertion policy configuration.  The documentation is out of date. I'll get that fixed. (Now updated!) In the meantime, the meaning/behavior of those elements is: 

  • AssertionXPath - specifies the XPath where the assertion is located
  • SignedElementXPath - specifies the XPath  which is signed

When you configure the policy this way, Apigee will verify the signature on the signed element based on the truststore you configure, and also verify that the assertion element is the same as the signed element or is a child of the signed element, and that the current time is within the range of the assertion validity times (NotBefore and NotOnOrAfter). Not necessarily in that order.

 

"unable to resolve xpath /samlp:Response/saml:EncryptedAssertion".

 

I am not sure the SAML policy handles EncryptedAssertion. Check the documentation on this one!

View solution in original post

Hi @dchiesa1 , Thank you for your response. I tried as you suggested and it is working as expected. I'm able to validate SAML token successfully. 

We are still searching for a way to do the same for an encrypted saml token. Please let us know if you find a way to implement the same. 

View solution in original post

2 REPLIES 2

Yes, I can help I think. At least I can help a little. 

First, the XPath element has been supplanted by two new elements,  AssertionXPath and SignedElementXPath. They should be used like this: 

 

 

<ValidateSAMLAssertion ignoreContentType="false" name="Validate-SAML-Assertion-1">

    <Source name="request">
        <Namespaces>
            ...
        </Namespaces>

        <!--<XPath>/samlp:Response/saml:Assertion</XPath>-->
        <AssertionXPath>/samlp:Response/saml:Assertion</AssertionXPath>
        <SignedElementXPath>/samlp:Response</SignedElementXPath>
    </Source>
    ...
</ValidateSAMLAssertion>

 

 

You should no longer use the sole XPath element in your ValidateSAMLAssertion policy configuration.  The documentation is out of date. I'll get that fixed. (Now updated!) In the meantime, the meaning/behavior of those elements is: 

  • AssertionXPath - specifies the XPath where the assertion is located
  • SignedElementXPath - specifies the XPath  which is signed

When you configure the policy this way, Apigee will verify the signature on the signed element based on the truststore you configure, and also verify that the assertion element is the same as the signed element or is a child of the signed element, and that the current time is within the range of the assertion validity times (NotBefore and NotOnOrAfter). Not necessarily in that order.

 

"unable to resolve xpath /samlp:Response/saml:EncryptedAssertion".

 

I am not sure the SAML policy handles EncryptedAssertion. Check the documentation on this one!

Hi @dchiesa1 , Thank you for your response. I tried as you suggested and it is working as expected. I'm able to validate SAML token successfully. 

We are still searching for a way to do the same for an encrypted saml token. Please let us know if you find a way to implement the same.