Integrating ADFS 2.0 and 3.0 with OAM: Pre-Requisites

This article describes how to integrate OAM (11.1.2.2.0 or later) with ADFS 2.0/3.0 for Federation SSO using the SAML 2.0 protocol. The integration covers:

• Pre-requisites (this article)

• ADFS 2.0/3.0 as the IdP and OAM as the SP

• ADFS 2.0/3.0 as the SP and OAM as the IdP

The SAML 2.0 integration is based on:

• Email address that is used as the NameID format

• The NameID value contains the user’s email address

• The HTTP POST binding is used to send the SAML Assertion to the SP

• Users exist in both systems, with each user having the same email address so that it can be used as the common user attribute.

ADFS 2.0 is available in Windows 2008 R2, while ADFS 3.0 is available in Windows 2012 R2. The article showcases screenshots for ADFS 3.0, while the documented steps apply to both versions. In this first article, we discuss the prerequisites.

Pre-Requisites

In order to integrate with ADFS using the SAML 2.0 protocol, OAM must be configured to use HTTPS/SSL as their endpoints. Failure to do so results in ADFS not accepting the OAM SAML 2.0 Metadata when establishing Federation Trust.

When integrating ADFS as an IdP with OAM as an SP, the following points need to be taken into account:

• By default, ADFS IdP encrypts the SAML Assertion when sending it to the SP using AES-256, and by default the JDK used in the OAM deployment cannot use strong cryptography such as AES-256. So

  • Either the JDK must be configured for strong cryptography

  • Or ADFS IdP must be configured to disable encryption

• If ADFS IdP is configured for authentication via HTTP Basic Auth or Windows Native Authentication, then the user can never be logged out as:

  • The HTTP Basic Auth credentials cannot be removed from the browser once entered, unless the browser is closed

Note: This applies to other IdPs using HTTP Basic Auth to challenge the user

• The browser is always logged into ADFS when using Windows Native Authentication

• By default ADFS requires messages to be signed using SHA-256, while by default OAM uses SHA-1:

  • Either configure ADFS to use/accept SHA-1

  • Or configure OAM to use SHA-256 for signatures

Finally, before integrating OAM and ADFS for SAML 2.0, the metadata for the two servers must have been downloaded.

Enabling SSL

There are several ways to enable SSL on the public endpoints for OAM:

• If a load balancer is fronting OAM, SSL/HTTPS can be enabled/configured on the load balancer

• If OHS is fronting OAM, OHS is configured for SSL

• If no component is fronting OAM, then the WLS server where OAM is running can be configured for SSL/HTTPS

Once the component (Load balancer, OHS or WLS) has been configured for SSL, the OAM configuration needs to be updated to reference the new endpoint as its public URL:

1. Go to the OAM Administration Console: http(s)://oam-admin-host:oam-adminport/oamconsole.

2. Navigate to Configuration , Access Manager Settings.

3. Set the OAM Server Host to the hostname of the public endpoint.

4. Set the OAM Server Post to the SSL port of the public endpoint.

5. Set the OAM Server Protocol to https.

6. Click Apply.

Description of the illustration Enabling_SSL.jpg

Note: After making those changes, retrieving the OAM SAML 2.0 Metadata contains the new https URLs.

Strong Encryption

As mentioned, by default, ADFS IdP encrypts the SAML Assertion when sending it to the SP using AES-256 which is considered by Java as a strong cipher (as opposed to “normal strength” such as AES-128, AES-192, 3DES).

Due to legal export reasons, JDK cannot be shipped with strong ciphers enabled in JCE: the administrator/integrator/developer must download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction policy.

To update the JCE Unlimited Strength Jurisdiction policy files to support strong encryption such as AES-256, execute the following steps:

1. Determine the major Java version used in the OAM deployment.

2. Locate the JDK folder used by OAM Execute: $JDK_HOME/bin/java -version.

3. The major version will be printed (either 6 or 7).

4. Download the JCE Unlimited Strength Jurisdiction policy.

5. If you are using JDK 7:

   1. http://www.oracle.com/technetwork/java/javase/downloads/index.html

6. If you are using JDK 6:

   1. http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archivedownloads-java-plat-419418.html

7. Unzip the contents of the downloaded ZIP file to a temporary folder.

8. Copy the unzipped local_policy.jar and US_export_policy.jar files your following JDK’s directory (this operation overwrites the local_policy.jar and US_export_policy.jar files present in that folder):

$JDK_HOME/jre/lib/security/

9. Restart the WLS Servers in the WLS domain to apply the changes.

To configure ADFS to disable encryption when sending the SAML Assertion to an SP, perform the following steps:

1. Go to the machine where ADFS is deployed.

   1. If ADFS 2.0 is used, click Start Menu , Programs , Administrative Tools , Windows PowerShell Modules

   2. If ADFS 3.0 is used, click Start Menu , Administrative Tools , Active Directory Module for Windows PowerShell

2. Execute the following command (replace RP_NAME with the SP name used to create the partner in ADFS):

   set-ADFSRelyingPartyTrust –TargetName“RP_NAME” –EncryptClaims $False

ADFS Logout

The SAML 2.0 protocol defines a logout profile where each Federation partner involved in a Federation SSO for the current user’s session is notified of the user signing out. This allows the various Federation partners to terminate the user’s session in their SSO domain.

ADFS IdP provides different ways to authenticate the user when a Federation SSO is being performed:

• FORM based authentication where

• The server displays a login page

• The user enters the credentials and submit them

• HTTP Basic Authentication

• Where the server returns a 401 status code to the browser

• The browser collects the user’s credentials

• The browser presents the credentials to the ADFS server

Note: The browser keeps the credentials and provide them to the ADFS server anytime the browser accesses ADFS, until the browser is closed

• Integrated Windows Authentication where ADFS leverages the user authentication state in the Windows environment: in this case, since the user is already logged into Windows, the user is automatically authenticated without any user interaction

Let’s look at the effect (or non-effect) of SAML 2.0 logout depending on how the user is authenticated:

• SP starts a Federation SSO operation with ADFS IdP

• ADFS IdP needs to authenticate/identify the user

• If FORM based authentication is used, ADFS displays a login page and the user enter its credentials

• If HTTP Basic Auth is used, ADFS returns 401 response code, the browser collects the credentials from the user and presents them to ADFS

• If Integrated Windows Authentication is used, the browser gets automatically a Kerberos/NTLMSSP token from the Windows Domain Controller / KDC that it presents to the ADFS server. There is no user interaction.

• User is redirected to SP with a SAML Assertion

• User initiates SAML 2.0 logout from the SP

• SP redirects the user to ADFS IdP for SAML 2.0 Logout

• ADFS clears cookies from the user’s browser (but not cached HTTP Basic Auth credentials if used previously)

• Logout is done

• In the same browser, SP starts a Federation SSO operation with ADFS IdP

• ADFS IdP needs to authenticate/identify the user

• If FORM based authentication is used, ADFS displays a login page and the user enter its credentials: user is challenged and needs to provide its credentials.

• If HTTP Basic Auth is used, ADFS returns 401 response code, the browser cached the credentials collected earlier and thus automatically presents them to ADFS. There is no user interaction.

• If Integrated Windows Authentication is used, the browser gets automatically a Kerberos/NTLMSSP token from the Windows Domain Controller / KDC that it presents to the ADFS server. There is no user interaction.

So if HTTP Basic Auth or Integrated Windows Authentication is used as the authentication mechanism at ADFS 2.0 IdP, after a logout, the user will still be “logged in” at the IdP, and executing a new Federation SSO will not trigger the user being challenged and results with the user being automatically authenticated at the SP, after Federation SSO is done.

Important Note: The behavior seen with logout also applies to other IdPs (OAM for example), that are using HTTP Basic Auth as the authentication mechanism

SAML 2.0 Metadata

To download the SAML 2.0 Metadata from the ADFS 2.0/3.0 server:

1. Open a browser

2. Go to the ADFS 2.0/3.0 Metadata publishing service:

https://adfs-host:adfsport/FederationMetadata/2007-06/FederationMetadata.xml

1. Save the Metadata locally using the Save As button in the browser

To download the SAML 2.0 Metadata from OAM:

1. Open a browser

2. Go to the OAM Metadata publishing service: http(s)://oam-runtime-host:oam-runtimeport/oamfed/idp/metadata or http(s)://oam-runtime-host:oam-runtimeport/oamfed/sp/metadata

3. Save the Metadata locally using the Save As button in the browser

Note: be sure to have enabled SSL in OAM first before download the OAM metadata, as the metadata contains the OAM URLs.

SHA-256 vs SHA-1

After having setting up Federation between OAM and ADFS, you need to:

• Either configure ADFS 2.0 to use/accept SHA-1

• Or configure OAM to use SHA-256 for signatures

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

---

Title and Copyright Information

Integrating ADFS 2.0 and 3.0 with OAM Pre-Requisites Continued

F60932-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.