"Request could not be validated" message generated processing incoming SAML2 AUthnRequest

  • Document ID:7010728
  • Creation Date:03-Sep-2012
  • Modified Date:03-Sep-2012
    • Micro Focus Products:
      Access Manager (NAM)

Environment

NetIQ Access Manager 3.2 acting as a SAML2 Identity Provider (IdP)
RGA’s serviceNow Application running as a SAML2 Service Provider (SP)
SP initiated login request to the IdP

Situation

Access Manager setup as a SAML2 Identity (IdP) Server, where we try and Single Sign On with RGA’s serviceNow SAML2 Service Provider (SP) after the SAML authentication at the IdP server. The setup was to implement the SP initiated SSO functionality where the users would hit the serviceNow SAML2 SP first, and automatically be redirected over to the Access Manager IdP server to enter their credentials. The SP metadata was imported into the IdP SAML2 setup without issues and the IdP was configured to send the appropriate assertion back to the SP after authentication.

Once the users accessed the serviceNow SP and were redirected to the IdP server for authentication, the IdP login page would never appear and the users would simply see a generic serviceNow home page instead. No indication of any error was reported to the browser, but the catalina.out file on the IdP server did indicate that the "Request could not be validated".

Resolution

Make sure that the SPNameQualifier tag in the SAML2 Authentication Request from the serviceNow SP included the same entry as the serviceNow 'EntityID' entry from the metadata. A second option would be to simply remove the SPNameQualifier from the SAML2 AUthentication Request.

Cause

The first thing to do with SAML isues such as this is to enable the IDP logging SAML2 component to DEBUG and apply the change. Once done, the IDP logs will include details on the Authentication request and responses, and potential sources of errors. In the example above, doing this allowed us to identify that the source of the problem was the incoming AuthnRequest from the SP. As soon as the Access Manager IDP server processed this request, it responded with an AUthnResponse where the SAML status was "Responder". This is a generic SAML response status indicating that the IDP could not process the incoming request correctly.

Looking at the incoming request in more detail, and the specific attributes allowed us to home in on the source of the problem (the SPNameQualifier entry). The SPNameQualifier tag from any SAML request must include the EntityID entry defined in the metadata for the host generating the request. In our case below, this did not prove true. Comparing a working (with a different SAML2 SP) and this non working case, the only change in the request parameters was the SPNameQualifier entry. Researching this entry in more details, we could see the following from the logs:

Type: received
 RelayState: https://randev.service-now.com/nav_to.do?uri=sysapproval_approver.do?sys_id=262a469499a76c00d7ea6843423a4c6b
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"    AssertionConsumerServiceURL=https://randev.service-now.com/navpage.do
    ForceAuthn="false"
    ID="SNCddd88c3406b74f10ef6b59f5e0c66ff0"
    IsPassive="false"
    IssueInstant="2012-08-29T17:16:54.933Z"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    ProviderName="https://randev.service-now.com/navpage.do"
    Version="2.0">

<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://randev.service-now.com</saml2:Issuer>

<saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" SPNameQualifier="https://randev.service-now.com/navpage.do"/><saml2p:RequestedAuthnContext Comparison="exact">

<saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>

</saml2p:RequestedAuthnContext>

</saml2p:AuthnRequest>
************************* End SAML2 message ****************************</msg></amLogEntry>

<amLogEntry seq="17415" d="2012-08-29T17:16:55Z" lg="SAML2" lv="WARNING" th="14" ><msg>Event Id: 3014667, Note 1: 5B3EFDE09389F9968AC901702D8930B7, Note 2: https://securelogin.rane.com/nidp/saml2/metadata, Note 3: Request could not be validated, Numeric 1: 0, Data: 198.190.171.234</msg></amLogEntry>
<amLogEntry seq="17416" d="2012-08-29T17:16:55Z" lg="SAML2" lv="DEBUG" th="14" >

As soon as we processed this request and before the response was sent back from the IDP server with the status of responder, the message that the 'Request could not be validated' was displayed. Looking at the metadata for the serviceNow SP, we had the following entries:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://randev.service-now.com"> <SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://randev.service-now.com/navpage.do" /> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat> <AssertionConsumerService isDefault="true" index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://randev.service-now.com/navpage.do"/> </SPSSODescriptor> </EntityDescriptor>

 

 The one major difference between a working and non-working setup is the NameIDPolicy section - and specifically the SPNameQualifier. The SPNameQualifier is usually used in the scenario where a SAML proxy may be in place, so that we find out who originated the SAML request/response. As far as I know, this SPNameQualifier must match the EntityID of the node - in our case, the EntityID is "https://randev.service-now.com" but the SPNameQualifier is https://randev.service-now.com/navpage.do. This could be the reason - can we get the SP to change their tag value, or remove it?

 

SPNameQualifier [Optional]
Further qualifies a name with the name of a service provider or affiliation of providers. This
attribute provides an additional means to federate names on the basis of the relying party or
parties.

 

In Section 8.3.7 it says:

 

The element's SPNameQualifier attribute, if present, MUST contain the unique identifier of the service
provider or affiliation of providers for whom the identifier was generated (see Section 8.3.6). It MAY be
omitted if the element is contained in a message intended only for consumption directly by the service
provider, and the value would be the unique identifier of that service provider.

 

The unique identifier is the EntityID. Tey are not using this. If I look at our code, I see the following:

 

  protected SAML2AuthnResponse handleAuthnRequest(SAML2AuthnRequest authnRequest, boolean firstTime)
    throws NIDPException
    {
        // ID of SP sending request           
        String identityID = authnRequest.getSPNameQualifier(); ********************* problem!

 

     // Validate the requesting SP and access point
        boolean valid = authnRequest.validate(m_Me,firstTime);

 

Tak ecare, neil