Integrating ADFS 2.0/3.0 with OIF: Pre-Requisites

In the next three articles, I will describe how to integrate OIF (11.1.2.2.0 or later) with ADFS 2.0/3.0 for Federation SSO using the SAML 2.0 protocol. The integration will cover:

  • Pre-requisites (this article)
  • ADFS 2.0/3.0 as the IdP and OIF as the SP (read article here)
  • ADFS 2.0/3.0 as the SP and OIF as the IdP (read article here)

The SAML 2.0 integration will be based on:

  • Email address will be used as the NameID format
  • The NameID value will contain the user’s email address
  • The HTTP POST binding will be used to send the SAML Assertion to the SP
  • Users will 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 articles will showcase screenshots for ADFS 3.0, while the documented steps will apply to both versions.

In this first article, I will discuss the pre-requisites.

 

Pre-Requisites


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

When integrating ADFS as an IdP with OIF 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/OIF 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 OIF uses SHA-1:
    • Either configure ADFS to use/accept SHA-1
    • Or configure OIF to use SHA-256 for signatures

Finally, before integrating OIF 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/OIF:

  • If a load balancer is fronting OAM/OIF, SSL/HTTPS can be enabled/configured on the load balancer
  • If OHS is fronting OAM/OIF, OHS will be configured for SSL
  • If no component is fronting OAM/OIF, 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:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Configuration -> Access Manager Settings
  • Set the OAM Server Host to the hostname of the public endpoint
  • Set the OAM Server Post to the SSL port of the public endpoint
  • Set the OAM Server Protocol to https
  • Apply

Note: after making those changes, retrieving the OIF SAML 2.0 Metadata will contain 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:

  • Determine the major Java version used in the OAM/OIF deployment:
    • Locate the JDK folder used by OAM/OIF
    • Execute:
      $JDK_HOME/bin/java -version
    • The major version will be printed (either 6 or 7)
  • Download the JCE Unlimited Strength Jurisdiction policy
    • If you are using JDK 7:
      http://www.oracle.com/technetwork/java/javase/downloads/index.html
    • If you are using JDK 6:
      http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-plat-419418.html
  • Unzip the contents of the downloaded ZIP file to a temporary folder
  • Copy the unzipped local_policy.jar and US_export_policy.jar files your following JDK’s directory (this operation will overwrite the local_policy.jar and US_export_policy.jar files present in that folder):
    $JDK_HOME/jre/lib/security/
  • 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:

  • Go to the machine where ADFS is deployed
  • If ADFS 2.0 is used, click Start Menu -> Progams -> Administrative Tools -> Windows PowerShell Modules
  • If ADFS 3.0 is used, click Start Menu -> Administrative Tools -> Active Directory Module for Windows PowerShell
  • 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 will display a login page
    • The user will enter the credentials and submit them
  • HTTP Basic Authentication
    • Where the server will return a 401 status code to the browser
    • The browser will collect the user’s credentials
    • The browser will present the credentials to the ADFS server
    • Note: the browser will keep 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 will be 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 will get automatically a Kerberos/NTLMSSP token from the Windows Domain Controller / KDC that it will present 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 will get automatically a Kerberos/NTLMSSP token from the Windows Domain Controller / KDC that it will present 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 will result 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 (OIF for example), that are using HTTP Basic Auth as the authentication mechanism

I will discuss SAML 2.0 Federation logout in a future article.

SAML 2.0 Metadata


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

Open a browser

  • Go to the ADFS 2.0/3.0 Metadata publishing service:
    https://adfs-host:adfs-port/FederationMetadata/2007-06/FederationMetadata.xml
  • Save the Metadata locally using the Save As button in the browser

To download the SAML 2.0 Metadata from OIF:

  • Open a browser
  • Go to the OIF  Metadata publishing service:
    http(s)://oam-runtime-host:oam-runtime-port/oamfed/idp/metadata
    or http(s)://oam-runtime-host:oam-runtime-port/oamfed/sp/metadata
  • 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 OIF metadata, as the metadata will contain the OAM/OIF URLs.

SHA-256 vs SHA-1


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

  • Either configure ADFS 2.0 to use/accept SHA-1
  • Or configure OIF to use SHA-256 for signatures


In the next article, I will cover the integration between ADFS as an IdP and OIF as an SP.
Cheers,
Damien Carru



Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Damien Carru is a member of the Oracle Identity Management organization, focusing on Federation and SSO. This blog will cover Federation use cases involving Oracle Access Manager, Oracle Identity Federation and Oracle Security Token Service

Search

Categories
Archives
« February 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
       
       
Today