Sun Java System Access Manager and Sun Java System Federation Manager FAQ: Liberty Alliance and Security Assertion Markup Language (2)

• SAML 1.x
  • How do I resolve the assertion MinorVersion too low or MinorVersion too high?
  • How do I enable basic authentication with a remote SAML producer for an Artifact Profile?
  • How do I resolve the error that the SOAP Receiver has received requests from an untrusted site?
  • How do I resolve the error that the assertion time in the SAML response is invalid?
• SAML 2.x
  • How does SAML 2.0 Authentication Context mapping work? What are the configurations?
  • How do I set up SAML 2.0 SSO for the users stored in another directory in the LDAP Version 3 Repository (LDAPv3) in an Access Manager 7.x subrealm?
  • How does the POST Profile compare to the Artifact Profile?

Q: How do I resolve the assertion MinorVersion too low or MinorVersion too high?

Since Access Manager supports the Security Assertion Markup Language (SAML) versions 1.0 and 1.1 protocols, the assertion's minor version can be 0 or 1. You must ensure that the minor version of the XML string of the input assertion is either 0 or 1.

To set up the preferred version:

1. Log in to the Access Manager Administration Console and click the SAML Service Configuration tab.
   
   
2. Under Trusted Partner Sites, select the appropriate entry to modify.
   
   
3. Add Version=1.0 or Version=1.1 as the new attribute.
   
   Afterwards, the outgoing SAML request contains the minorVersion=0 or minorVersion=1 attribute.

Alternatively, edit the AMConfig.properties file and define the version number for these two properties, for example, for version 1.1:

com.sun.identity.saml.assertion.version=1.1
com.sun.identity.saml.protocol.version=1.1

Note that these are global variables, that is, they apply to the entire server base. The attribute that's set up in the Administration Console (steps 1-3 above) applies to the partner or site only. Also, that attribute overrides the properties in the AMConfig.properties file.

Q: How do I enable basic authentication with a remote SAML producer for an Artifact Profile?

Do the following:

Note: In the steps below, the view name in the Access Manager Administration Console might vary according to the Access Manager releases.

First, enable the SAML service in the root organization:

1. Log in as the top-level administrator to the Access Manager Administration Console.
   
   
2. Go to the default organization and click the Identity Management tab.
   
   
3. Select the Services view.
   
   
4. Click Add.
   
   
5. Select the service SAML and click OK.

Next, create a user with the SAML service configured:

1. Select the User view in the default organization.
   
   
2. Click the New button to create a new user.
   
   
3. Select the service SAML and click Next.
   
   
4. Fill in the fields with the user information and click Finish.
   
   
5. Select Services in the User view and click Edit for the SAML service.
   
   
6. Fill in the SAML User and SAML User Password fields.
   
   These are the user ID and password required for remote basic authentication.

Finally, configure the trusted partner for the remote site:

1. Click the Service Management tab and select SAML Service.
   
   
2. Under "Trusted partner," add an entry for the remote side, configure the source ID, service endpoints, and so forth.
   
   
3. Add the following fields for basic authentication:
   
   AuthType=BASICAUTH
User=
   
   Here is an example of the value for the User=value:
   
   

   uid=abc,ou=people,dc=sun,dc=com

    
   Note: The value must be the full distinguished name of the user.

Q: How do I resolve the error that the SOAP Receiver has received requests from an untrusted site?

While the user is performing SSO, if the browser displays the SC_FORBIDDEN error, the amSAML debug log shows this message:

Also, the amSAML.error log shows this message:

To resolve the problem, do the following:

1. Log in to the Access Manager Administration Console and go to the SAML Service Configuration page.
   
   
2. Under Trusted Partner Sites on the right pane, ensure that the proper entry contains the hostlist attribute, set hostlist=certAlias (if client authentication is on), and add the IP address or distinguished name of the remote machine.

Q: How do I resolve the error that the assertion time in the SAML response is invalid?

This error might have been caused by one of these three scenarios:

• The two SSO machines are out of sync with respect to time. As a resolution, run the UNIX command date on the two machines to check their time and sync the readings, if appropriate.
  
  
• The length for Assertion Timeout is too short. The current time must fall within the validity interval of the two attributes NotBefore and NotOnOrAfter. If the transmission takes longer than that interval, increase the value for Assertion Timeout in the SAML Service Configuration page from the Access Manager Administration Console.
  
  
• The NotBefore attribute is improperly configured. You can tune the Assertion Skew Factor for NotBefore on the SAML Service Configuration page.

Q: How does SAML 2.0 Authentication Context mapping work? What are the configurations?

The SAML 2.0 Authentication Context mapping capability maps a standard authentication context class reference (for example, PasswordProtectedTransport) to Access Manager's authentication scheme (for example, module=LDAP) on the identity provider (IdP). Authentication Context also sets the appropriate authentication level on the user's SSO token on the service provider (SP).

You can configure two Authentication Context mappers:

• SPAuthnContextMapper — Configure this mapper on the SP. Map HTTP request parameters to RequestedAuthnContext, which will be sent to the IdP with the authentication level to be set on the SSO token.
  
  This mapper employs three attributes in the SP's extended metadata:
  
  
  • SPAuthnContextMapper — Specifies the mapper implementation class name.
    
    
  • spAuthncontextClassrefMapping — Specifies the mapping of the class reference and authentication level.
    
    The value format is authnContextClassRef | authlevel [| default], for example, PasswordProtectedTransport|4.
    
    
  • spAuthncontextComparisonType — Specifies the comparison type in the authentication request.
  
  
• IdPAuthnContextMapper — Configure this mapper on the IdP. Map the incoming authentication request from the SP to the authentication scheme (module/role/user/service-based authentication). Afterwards, return the authentication context class reference.
  
  This mapper employs two attributes in the IdP's extended metadata:
  
  
  • IdPAuthnContextMapper — Specifies the mapper's class name.
    
    
  • idpAuthncontextClassrefMapping — Specifies the mapping between the name of the Authentication Context class reference and authentication scheme.
    
    The value format is authnContextClassRef | authnType=authnValue | authnType=anthnValue | ..., for example, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTran sport|module=LDAP
    
    This mapping maps the class reference PasswordProtectedTransport to the module=LDAP scheme.

For example, to map PasswordProtectedTransport to authentication level 4 on the SP and apply LDAP as the authentication scheme on the IdP:

1. Edit the current SP extended metadata and set the mapping for the context class reference:
   
   

   ... PasswordProtectedTransport|4

    
   
2. Load the updated metadata with the command saml2meta.
   
   
3. Edit the current IdP extended metadata and set the mapping for the context class reference:
   
   

   ... urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport |module=LDAP ...

    
   
4. Load the updated metadata with the command saml2meta.
   
   
5. Access the SP's SSO initial JavaServer Pages (JSP) page by specifying the AuthnContextClassRef parameter, for example:
   
   

   http://hostname:portnumber/uri/ spSSOInit.jsp?metaAlias=sp&idpEntityID=idp.sun.com&AuthnContextClassRef= PasswordProtectedTransport

The workflow proceeds as follows:

1. The user accesses the spSSOInit.jsp page with the AuthnContextClassRef query parameter, for example, AuthnContextClassRef=PasswordProtectedTransport.
   
   
2. Access Manager invokes SPAuthnContextMapper to map the page to RequestedAuthnContext and the authentication level.
   
   
3. The SP sends the authentication request with RequestedAuthnContext to the IdP.
   
   
4. The IdP processes the request, invokes IdPAuthnContextMapper to map the incoming request to an authentication scheme, and redirects the user to the authentication service with that authentication scheme, for example, http://hostname:portnumber/uri/UI/Login?module=LDAP.
   
   
5. After successful authentication, the authentication service redirects the user to the IdP for processing and constructs a response based on the mapped authentication class reference.
   
   
6. After validating the response and creating an SSO token, the IdP redirects the user to the SP's assertion consumer and sets the mapped authentication level to the user's SSO Token (step 2).
   
   

Q: How do I set up SAML 2.0 SSO for the users stored in another directory in the LDAP Version 3 Repository (LDAPv3) in an Access Manager 7.x subrealm?

Follow this procedure:

Note: Perform steps 1-3 on both the IdP and SP machines.

1. Install Access Manager 7.x.
   
   
2. Install the SAML 2.0 plug-in.
   
   
3. Configure the subrealm to work with the users stored in another LDAPv3 directory.
   
   
   1. Create a subrealm called, for example, /cur.
      
      For details, see Chapter 5 in the Sun Java System Access Manager Administration Guide.
      
      
   2. Configure the LDAPv3 data store plug-in for this subrealm.
      
      
      1. Add the SAML 2.0 plug-in object class and attributes to the LDAPv3 data store, which contains the user data: Load saml2_sds_schema.ldif and saml2_sds_index.ldif for Sun Java System Directory Server, followed by saml2_ad_schema.ldif for Microsoft Active Directory.
         
         
      2. Add the sunFMSAML2NameIdentifier object class to all the existing users, if necessary.
         
         The ldif files that contain the definitions for the object classes and attributes are at /SUNWam/saml2/ldif. You can add object classes and attributes either in the Administration Console or with the ldapmodify command. For details, see "To Install the SAML v2 IdP Discovery Service" in the Sun Java System SAML v2 Plug-in for Federation Services User's Guide.
         
         
      3. Create an LDAPv3 data store for this subrealm.
         
         For details, see "LDAPv3 Data Store" in the Sun Java System Access Manager 7 Administration Guide.
         
         While configuring the data store for the subrealm, add sunFMSAML2NameIdentifier to the LDAP User Object Class and sun-fm-saml2-nameid-infokey and sun-fm-saml2-nameid-info to LDAP User Attributes.
         
         After configuration, you can view all the existing users and create new users by choosing Subrealm > Subjects.
         
         
      4. Configure the subrealm's authentication against the users stored in the existing LDAPv3 directory.
         
         For details, see "Configuring Authentication" in the Sun Java System Access Manager 7 Administration Guide.
   
   
4. Create a metadata template on the IdP and SP machines.
   
   
   1. On the IdP machine, type:
      
      /SUNWam/bin/saml2meta template -u amadmin -w password -d /cur/idp -e http://www.idp.com -m idpMeta.xml -x idpExtended.xml
      
      
   2. On the SP machine, type:
      
      /SUNWam/bin/saml2meta template -u amadmin -w password -s /cur/sp -e http://www.sp.com -m spMeta.xml -x spExtended.xml
   
   
5. Configure SAML 2.0 on the IdP machine.
   
   
   1. Import the hosted IdP and remote SP metadata to the subrealm /cur.
      
      For the hosted IdP, type:
      
      /SUNWam/bin/saml2meta import -u amadmin -w password -r /cur -m idpMeta.xml -x idpExtended.xml
      
      For the remote SP, copy spMeta.xml from the SP machine and type:
      
      /SUNWam/bin/saml2meta import -u amadmin -w password -r /cur -m spMeta.xml
      
      
   2. Create a Circle of Trust (COT) under the subrealm. Type:
      
      /SUNWam/bin/saml2meta cotcreate -u amadmin -w password -r /cur -t curcot
      
      
   3. Add the IdP and SP to the COT. Type:
      
      /SUNWam/bin/saml2meta cotadd -u amadmin -w password -r /cur -t curcot -e http://www.idp.com

/SUNWam/bin/saml2meta cotadd -u amadmin -w password -r /cur -t curcot -e http://www.sp.com
   
   
6. Configure SAML 2.0 on the SP machine.
   
   
   1. Import the remote IdP and hosted SP metadata to the subrealm /cur.
      
      For the remote IdP, copy spMeta.xml from the IdP machine and type:
      
      /SUNWam/bin/saml2meta import -u amadmin -w password -r /cur -m idpMeta.xml
      
      For the hosted SP, type:
      
      /SUNWam/bin/saml2meta import -u amadmin -w password -r /cur -m spMeta.xml -x spExtended.xml


   2. Create a COT under the subrealm. Type:
      
      /SUNWam/bin/saml2meta cotcreate -u amadmin -w password -r /cur -t curcot
      
      
   3. Add the IdP and SP to the COT. Type:
      
      /SUNWam/bin/saml2meta cotadd -u amadmin -w password -r /cur -t curcot -e http://www.idp.com

/SUNWam/bin/saml2meta cotadd -u amadmin -w password -r /cur -t curcot -e http://www.sp.com
      
      
   4. Configure SAML2 as one of the Module Instances under the subrealm.