Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-13604

IdP Proxy relays wrong AuthnContextClassRef if the AuthLevel requested by the SP is not 0

    XMLWordPrintable

    Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 6.0.0.4
    • 6.5.0, 6.0.0.6, 6.0.1
    • SAML
    • AM Sustaining Sprint 55, AM Sustaining Sprint 56
    • 5

      Description

      Bug description

      In an IdP Proxy scenario with LOA defined, if the SP starts federation and requests a LOA of level 2 (for example), the IdP correctly sends an AuthnContextClassRef of level 2, but the Proxy sends an AuthnContextClassRef of level 0.

      How to reproduce the issue

      1. Set up IDP Proxy configuration with LOA following information from https://wikis.forgerock.org/confluence/display/openam/SAMLv2+IDP+Proxy+Part+2.+Using+an+IDP+Finder+and+LOAs 
      2. Verify it is working fine when starting federation with the default authN context (adapt as needed):
        http://sp.example.com:38080/openam/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&idpEntityID=http://proxy.example.info:48080/openam
      1. Now test with LOA such as:
        http://sp.example.com:38080/openam/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&idpEntityID=http://proxy.example.info:48080/openam&AuthnContextClassRef=http://foo.example.com/assurance/loa2
      Expected behaviour
      Federation is successful as SP receives a correct response containing: 
      
      <saml:AuthnContextClassRef>
      http://foo.example.com/assurance/loa2
      </saml:AuthnContextClassRef>
      Current behaviour
      SP throws a HTTP 500 because it receives a Response with:
      
      <saml:AuthnContextClassRef>
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>

      The root cause is with the proxy instance of AM. Debug recording and SAML tracer flow is attached to this bug report.

      Note that it was working in 13.5, according to customer, but I have not tested in any other version than 6.0.0.4. 

      Code analysis

      As far as I can see, the problem happens in FMSessionProvider.java - createSession, where the CTS session is created without authentication level attached to it:

      FMSessionProvider.java
      ...
      // set all properties in the info map to sso token
      try {
          Iterator it = info.keySet().iterator();
          while (it.hasNext()) {
              String keyName = (String) it.next();
              if (keyName.equals(AUTH_LEVEL)) {
                  continue;
              }
              String keyVal = (String) info.get(keyName);
              ssoToken.setProperty(keyName, 
                  StringUtils.getEscapedValue(keyVal));
          }
      

      When retrieving the authLevel to create its response, AM6 (as IDP Proxy) uses the CTS session and finds a authLevel value of 0. It then uses an AuthN context that corresponds to such level.

        Attachments

          Issue Links

            Activity

              People

              sfraser Sam Fraser
              nathalie.hoet Nathalie Hoet
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: