Executing external contract on AG protected resource fails to redirect to target after authentication succeeds at remote SAML2 Identity Server

  • Document ID:7011594
  • Creation Date:09-Jan-2013
  • Modified Date:09-Jan-2013
    • Micro Focus Products:
      Access Manager (NAM)

Environment

NetIQ Access Manager 3.2
NetIQ Access Manager 3.2 Support Pack 1 applied
NetIQ Access Manager 3.2 Identity Server acting as SAML2 Service Provider as well as Liberty Identity Server
3rd Party SAML2 Identity Server

Situation

Access Manager setup so that when users access the Access Gateway Protected resources, they initially get redirected to the NAM Identity (IDP) Server where an contract with the 'external provider' flag enabled is executed. This contract is defined for a SAML2 setup that exists between the NAM Identity Server and a 3rd party SAML2 Identity server, so a SAML2 Authentication request is automatically sent to the 3rd party SAML2 Identity server. 

The user then authenticates at the remote SAML2 identity server, which generates an assertion back to the NAM IDP server. The NAM IDP server should validate the assertion and then redirect the user back to the original URL they were accessing ie. the AG protected resource initially hit.

In this setup, the users would successfully authenticate to the SAML2 Identity server, send the assertion back to the NAM IDP server but then get the NAM IDP portal page displayed instead of getting redirected back to the original URL. Looking at the catalina log files on the NAM IDP server, we could see the incoming assertion from the SAML2 Identity server, the local validation and authentication but then a request for additional interaction on the external contract we defined on the Access Gateway protected resource..

<amLogEntry> 2013-01-02T09:30:36Z VERBOSE NIDS Application: Authentication method FnrS/Password - Form requires additional interaction. </amLogEntry>

The SAML relationship between SP and IDP defined this contract as the authentication contract to be satisfied (IDP -> SAML2 -> SAML2 Identity Provider -> Authenitcation card) so it should not have requested this.

Resolution

Select the external contract (IDP -> Local -> contracts -> <$contract_satisfied_with_external_provider>) and make sure that the 'requested by' field is changed from the default 'Don not specify' to 'use types' where the allowable class is set to the 'AuthContextClassRef' defined in the assertion coming back from the 3rd Party SAML2 IDP server. In our case, this was urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport