NAM acting as SAML2 SP not redirecting to target protected resource after upgrade from 3.1 to 3.2 - just shows IDP portal page with message indicating that user has been authenticated for X minutes

NAM acting as a SAML2 SP, as well as a Liberty Identity Server for the Access Gateway. The setup was working well on 3.1, where users would hit the Access Gateway protected resource and get redirected to the NAM IDP server for authentication. The NAM IDP server would execute an external contract and get redirected to the remote 3rd party SAML2 Identity server. With a successful authentication there, an assertion would be sent back to the NAM SAML2 SP, which in turn would get sent to the Access Gateway where the user would display the right page.

Modify the 'Allowable class' setting on the External contract defined on the NAM IDP server used in this SAML relationship to include the value set in the assertion AuthnContextClassRef tag eg. if the 3rd party Identity server returns the following assertion

<saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">kjh@bla.com</saml:NameID><saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData InResponseTo="idRHlgGMcE4APYmUVuWSPsk6SIh5E" NotOnOrAfter="2013-05-14T20:06:46.409Z" Recipient="https://nam-idp.bla.com/nidp/saml2/spassertion_consumer"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions NotOnOrAfter="2013-05-14T20:06:46.409Z" NotBefore="2013-05-14T19:56:46.409Z"><saml:AudienceRestriction><saml:Audience>https://nam-idp.bla.com/nidp/saml2/metadata</saml:Audience></saml:AudienceRestriction></saml:Conditions>
<saml:AuthnStatement AuthnInstant="2013-05-14T20:01:46.408Z" SessionIndex="fu7VXaz7P8IS0nsn9U8JYn9WxWM"><saml:AuthnContext>
<saml:AuthnContextClassRef>DUBSDS-staging</saml:AuthnContextClassRef> **************
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema">
:

the 'Allowable class' field in the Contract defined for this Identity Server must include the DUBSDS-staging string.

WHen the assertion is consumed, we verify whether or not the assurance level we set on the contract (via the Allowable Class) is met. When dealing with 3rd party Identity Servers, this is typically in the form of a SAML authentication type (eg. urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport) or a string as shown above eg. NYSDS-staging. Failure to validate this assurance level indicates a failure to tie into the matching contact, and users will not be redirected to the original URL they were trying to access.

The catalina log file will show the following string indicating that the matching protected resource contract on the AG has not been satisfied.

<amLogEntry> 2013-05-14T20:01:46Z VERBOSE NIDS Application: Authentication method IDP Select requires additional interaction. </amLogEntry>