Access Manager IDP x509 Tomcat Dual Connector setup with clustered IDP servers fails

  • 7023228
  • 31-Jul-2018
  • 30-Jan-2019

Environment

  • Access Manager 4.4
  • Access Manager 4.4.1
  • Access Manager 4.4.2

Situation

Test Setup:
  • 1st Connector: idpa.kgast.nam.com:8443  (Node1 10.2.92.100 / Node2 .109)
  • 2nd Connector certauth.kgast.nam.com:8443 (Node1 10.2.92.99 / Node2 .108)

  • client with a hosts file
    ========================================
    idpa.kgast.nam.com  10.2.92.100
    certauth.kgast.nam.com 10.2.92.108

    ========================================

  • x509 contract has "id=X509"
  • My browser calls: "https://idpa.kgast.nam.com:8443/nidp/app?id=X509
  • In this scenario I start the authentication at node1 and get redirected to node2 in order to run the x509 authentication contract. As a next step I get redirected back to node1 and it reports that the users session has been authenticated. This emulates a content switch between the two IDP cluster nodes during the x509 authentication process. Node1 will need to retrieve the user session information from node2 by running a proxy request.

  • IDP server context.xml
    ==============================================
    <?xml version="1.0" encoding="UTF-8"?>
       <Context sessionCookiePath="/" sessionCookieDomain=".kgast.nam.com">
       <!-- Disable session persistence across Tomcat restarts -->
           <Manager pathname="" saveOnRestart="false"/>
       </Context>

    ==============================================

  • IDP server.xml connector:
    ==============================================
    <Connector NIDP_Name="connector" SSLEnabled="true" URIEncoding="utf-8" acceptCount="100" address="10.2.92.108" ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256" clientAuth="want" disableUploadTimeout="true" enableLookups="false" keystoreFile="/opt/novell/devman/jcc/certs/idp/connector.keystore" keystorePass="E303jzYO8g68eJ2" maxThreads="600" minSpareThreads="5" port="8443" scheme="https" secure="true" sslEnabledProtocols="SSLv2Hello,TLSv1.1,TLSv1.2" sslImplementationName="com.novell.nidp.common.util.net.server.NIDPSSLImplementation" protocol="org.apache.coyote.http11.Http11Protocol" sslProtocol="TLSv1.2" />
    ==============================================

  • Wildcard certificate used to natch domain "*.kgast.nam.com"
  • "certauth.kgast.nam.com" and "idpa.kgast.nam.com".

  • x509 method has been configured with the property:
    ==============================================
    "CONNECTOR_HOST https://certauth.kgast.nam.com:8443
    ==============================================

Test Scenario
  • A protected resource has been assigned to run the Secure/Name/Password Contract.
    When the PR gets accessed the user selects the x509 Card instead of executing Secure/Name/Password
    (same or higher security level as Secure/Name/Password).

  • During the Authentication process at the IDP server the user gets switched for the x509 authentication to another IDP cluster node. x509 authentication using the user certificate works fine and the user gets send back to the Access Gateway NESP (Embedded Service Provider) along with a SAML2 Artifact. The ESP retrieves the SAML2 Assertion but fails to authenticate the user
    =========================================================================
    <amLogEntry> 2018-05-11T09:42:36Z DEBUG NIDS Application:
    Method: IDPAuthenticationHandler.handleAuthentication
    Thread: ajp-nio-127.0.0.1-9009-exec-3
    Was authnResponse verified: Yes </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: IDP response validated successfully, now attempting to authenticate </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Session has consumed authentications: false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Authenticate by identity false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Session has consumed authentications: false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Use temporary identity false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Session has consumed authentications: false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z DEBUG NIDS Application:
    Method: IDPAuthenticationHandler.handleAuthentication
    Thread: ajp-nio-127.0.0.1-9009-exec-3
    Was authnResponse verified: Yes </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: IDP response validated successfully, now attempting to authenticate </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Session has consumed authentications: false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Authenticate by identity false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Session has consumed authentications: false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Use temporary identity false </amLogEntry>
    <amLogEntry> 2018-05-11T09:42:36Z VERBOSE NIDS Application: Session has consumed authentications: false </amLogEntry>
    ===========================================================================

Problem
  • the contract which has been send in the Assertion will be the URI of the x509 contract. The ESP expects to match the contract assigned to the PR Secure/Name/Password.

Resolution

  • This issue has been fixed with NAM 4.4.3.
  • For NAM 4.4.2 and engineering build is available which can be requested from support

Cause

  • The IDP cluster uses two JESSEIONID cookies with the Dual Connector setup
  • The initial created JESSEIONID cookie due to the request of executing the Secure/Name/Password contract does not get authenticated
  • Only the JESSIONDID cookie created by the second connector has been authenticated