Access Manager IDP x509 Tomcat Dual Connector fails with "The Web Browser experienced an error that did not allow it to successfully initiate the request"

  • 7023688
  • 30-Jan-2019
  • 01-Feb-2019

Environment

  • Access Manager 4.3.3
  • Access Manager 4.4.3

Test Setup:
  • legacy login pages have been enabled (problem does not happen with non legacy pages)
  • 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
    ========================================


  • 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
    ==============================================

Situation

  • user will access the IDP portal page at https://idpa.kgast.nam.com:8443/nidp/portal
  • user selects the x509 authentication card
  • browser will receive the redirect to the second connector

    HTTP/1.1 302
    Strict-Transport-Security: max-age=31536000

    X-Frame-Options: SAMEORIGIN
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    via-ESP: null,NIDPLOGGING.600105004 session33-FDDA41E571F19E079B7298E8F56BAE30, null,NIDPLOGGING.600105004 session33-FDDA41E571F19E079B7298E8F56BAE30,NIDPLOGGING.600105002 session220-FDDA41E571F19E079B7298E8F56BAE30
    Pragma: No-cache
    Cache-Control: no-cache
    Access-Control-Allow-Origin: https://idpa.kgast.nam.com:8443
    Access-Control-Allow-Methods: GET, POST, DELETE, PUT, OPTIONS
    Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
    Access-Control-Allow-Credentials: true
    Access-Control-Expose-Headers: Set-Cookie
    Location: https://certauth.kgast.nam.com:8443/nidp/app/login?id=X509&sid=0&option=credential&sid=0&uiDestination=contentDiv&sid=0
    Content-Length: 0


  • Brower client returns the error message:  "The Web Browser experienced an error that did not allow it to successfully initiate the request"

Resolution


  1. Make sure the Server Certificate has been configured to store both DNS names as subjectAltName

    X509v3 Subject Alternative Name:
    DNS:idpa.kgast.nam.com, DNS:certauth.kgast.nam.com, DNS:nam40.kgast.nam.com


  2. disable the "httpHeaderSecurity"  from within the "/opt/novell/nam/idp/conf/web.xml" by remarking the complete section <!-- -->

    On the NIDP server modify the "/opt/novell/nids/lib/webapp/WEB-INF/web.xml" to make use of the "ALLOW-FROM" and "antiClickJackingUri" directives instead of using "SAMEORIGIN"
<!--========================================================================================
  init params description for SameOriginFilter:
activate- This activates the filter.
  Specify a value "True" to activate the filter.
========================================================================================= -->
<filter>
    <filter-name>SameOriginFilter</filter-name>
    <description>The NIDP server anti-clickjacking filter.This filter adds 'X-FRAME-OPTIONS: SAMEORIGIN' header to http responses, and prevents cross domain framing of web pages as best as possible depending on browser compatibility.</description>
    <filter-class>com.novell.nidp.servlets.filters.jsp.SameOriginFramingFilter</filter-class>
        <init-param>
            <param-name>activate</param-name>
            <param-value>False</param-value>
        </init-param>
</filter>
<filter-mapping>
    <filter-name>SameOriginFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<filter>
    <filter-name> httpHeaderSecurity</filter-name>
    <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
    <async-supported>true</async-supported>
    <init-param>
        <param-name>hstsMaxAgeSeconds</param-name>
        <param-value>31536000</param-value>
    </init-param>
    <init-param>
        <param-name>antiClickJackingOption</param-name>
        <param-value>ALLOW-FROM</param-value>
        <!-- <param-value>SAMEORIGIN</param-value> -->
    </init-param>
    <init-param>
        <param-name>antiClickJackingUri</param-name>
        <param-value>*</param-value>
   </init-param>

</filter>

  • The redirect header should look now like:

    HTTP/1.1 302

    Strict-Transport-Security: max-age=31536000

    X-Frame-Options: ALLOW-FROM *

    X-Content-Type-Options: nosniff

    X-XSS-Protection: 1; mode=block

    via-ESP: null,NIDPLOGGING.600105004 session33-053C9CE88185B31750EF4124364D83BD, null,NIDPLOGGING.600105004 session33-053C9CE88185B31750EF4124364D83BD,NIDPLOGGING.600105002 session220-053C9CE88185B31750EF4124364D83BD

    Pragma: No-cache

    Cache-Control: no-cache

    Access-Control-Allow-Origin: https://idpa.kgast.nam.com:8443

    Access-Control-Allow-Methods: GET, POST, DELETE, PUT, OPTIONS

    Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization

    Access-Control-Allow-Credentials: true

    Access-Control-Expose-Headers: Set-Cookie

    Location: https://certauth.kgast.nam.com:8443/nidp/app/login?id=X509&sid=0&option=credential&sid=0&uiDestination=contentDiv&sid=0

    Content-Length: 0

Note: Usually it would be better to add both domains to <param-name>antiClickJackingUri</param-name> but this is not possible with the shipped tomcat filter therefore the only option is to set the wildcard "*". This paramter is not mullti - valued as per tomcat documentation

Cause

  1. Both tomcat connectors will make use of the same Certificate (assigned to the IDP BaseURL). If the certificate has not been configured with subjectAltNam including both DNS names (prinary and secondary connector) browser clients will fail to validate the server certificate with the ERR_CERT_COMMON_NAME_INVALID

  2. The X-Frame-Options: SAMEORIGIN prevents the browser from loading any content hosted on the second connector "https://certauth.kgast.nam.com:8443"

    X-Frame-Options Header

    The X-Frame-Options HTTP header field indicates a policy that specifies whether the browser should render the transmitted resource within a <frame> or an <iframe>.  Servers can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, which ensures that their content is not embedded into other pages or frames.

Additional Information

  • DENY A browser receiving content with this header field MUST NOT display this content in any frame.

  • SAMEORIGIN A browser receiving content with this header field MUST NOT display this content in any frame from a page of different origin than the content itself. If a browser or plugin cannot reliably determine whether or not the origin of the content and the frame are the same, this MUST be treated as "DENY". Please note that current implementations vary on the interpretation of this criteria. In some, it only allows a page to be framed if the origin of the top-level browsing context is identical to the origin of the content using the X-Frame-Options directive; in others, it may consider the origin of the framing page instead. Also see Section 2.3.2.2 for more details on the nesting of frames and variations in the handling of this header field by different browsers. In addition, refer to Section 4, paragraph 2 for the resulting potential security problems.

  • ALLOW-FROM (followed by a serialized-origin [RFC6454]) A browser receiving content with this header MUST NOT display this content in a frame from any page with a top-level browsing context of different origin than the specified origin.