"Request Denied" message returned by Identity Server when processing SAML2 authentication request

Administrator has setup a SAML2 trust relationship between ServiceNow, acting as the SAML2 Service Provider (SP), and NetIQ Access Manager Identity server (IDP) acting as the SAML2 Identity Provider. Both the IDP and SP initiated single sign on setups are expected to work. When hitting the IDP initiated interiste transfer URL, the user is prompted to authenticate at the IDP server and the single sign on succeeds.

When the user hits the SP initiated URL on the ServiceNow SP (https://rgadev.service-now.com/nav_to.do?uri=sysapproval_approver.do?sys_id=xxx for example), the user is sent to a ServiceNow portal page without getting single signed on, or error message as to why they were not single signed on. There appears to be no redirect to the SAML2 IDP server asking the user for credentials.

Make sure that the SPNameQualifier sent by the ServiceNow SP matches the EntityID of the SP metadata. Failure to adhere to these standards means that the AUthentication Request generated by the SP is rejected at the IDP server as an unknown provider.

Troubleshooting these type of SAML issues involves enabling DEBUG level logging at the IDP server (IDP -> Logging and mak esure component level logging for Application and SAML2 is set to DEBUG).

After doing this, the catalina log file on the IDP server displays all the SAML processing traffic, including the Authentication request, responses, etc. In our case, the first thing we need to do is look at the IDP logs for any incoming SAML authentication request. This will confirm that

a) the SP is sending it to the right location
b) the request information matches what we expect from the IDP setup and
c) that the IDP server generates an appropriate response.

In our case, we could see the incoming Authentication request, but the response indicated a processing error. The incoming request looks like the following:

Type: received RelayState: https://rgadev.service-now.com/navpage.do <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://rgadev.service-now.com/navpage.do"; ForceAuthn="false" ID="SNC04c853d28c0e2b0b22d5b6ccc40d2b95" IsPassive="false" IssueInstant="2012-08-08T18:50:45.753Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="https://rgadev.service-now.com/navpage.do"; Version="2.0"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://rgadev.service-now.com</saml2:Issuer><saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="https://rgadev.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>

and we respond with the following status (snippet for response)

 <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied"/></samlp:StatusCode></samlp:Status></samlp:Response>


This Responder status is an indication that the IDP server did not like the incoming request. This typically occurs when the validation of the request takes place and we cannot validate the issuer of the request or satisfy an attribute of the request eg.

a) the parameters in the incoming request do not match what we have imported in the SP metadata (need SP metadata to check this) or
b) we cannot satisfy one of the requested attributes from the AuthnRequest eg. SP asks for a transient NameID format yet the IDP server is defined to send another NameID format; the client requests the POST binding but the server has the response binding defined as artifact; the PasswordProtectedTransport type is not mapped to a corresponding NAM contract

When looking at these log files and comparing the non working and a workings setup, we could figure out the source of the problem. The following shows a similar authentication request from a GoogleApps SP

// Google SP to NAM IDP

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="keiiokbdhilppapfijagdmflklaafffkbalomnhb" Version="2.0" IssueInstant="2012-08-30T13:07:28Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" ProviderName="google.com" IsPassive="false" AssertionConsumerServiceURL="https://www.google.com/a/ag4cdemo.info/acs"; > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">google.com</saml:Issuer> <samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" /> </samlp:AuthnRequest>

This is pretty similar to our one ...

Type: received RelayState: https://rgadev.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://rgadev.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://rgadev.service-now.com/navpage.do"; Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://rgadev.service-now.com</saml2:Issuer<https://rgadev.service-now.com%3c/saml2:Issuer>> <saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" SPNameQualifier="https://rgadev.service-now.com/navpage.do"/><saml2p:RequestedAuthnContext<https://rgadev.service-now.com/navpage.do%22/%3E%3Csaml2p: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.rgare.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" > <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://rgadev.service-now.com<;https://rgadev.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://rgadev.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://rgadev.service-now.com/navpage.do"/> </SPSSODescriptor> </EntityDescriptor>

The one major difference between the working and non working one 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. The SPNameQualifier must match the EntityID of the node - in our case, the EntityID is "https://rgadev.service-now.com<;https://rgadev.service-now.com/>" but the SPNameQualifier is https://rgadev.service-now.com/navpage.do. A fix could be done by getting the SP to change their tag value (which we did), or simply remove it? From the COre SAML2 specs, the SPNameQualifier is documented as:

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.