ADFS with OIF Pre_requisites Damien Carru blog

Integrating ADFS 2.0/3.0 with OIF: Pre-Requisites

By Damien Carru-Oracle on Apr 04, 2014

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

Comments

Post a Comment

Popular posts from this blog

VMware fix for Invalid manifest and ova file import failed errors

Image
Recently we got a OVA file for a virtual machine. The vendor instructions were to import the ova file in vmware Workstation, Player for Windows/Linux, Fusion for Mac, and VirtualBox as well.  The instructions were to take the available package and launch the VM with VMware workstation. The package contained  Module.mf, Module.ovf and Module-disk.vmdk and a Module.ova file. The .mf and .ovf file were 2 KB each whereas the vmdk was several gigs. The package also contained a Module.ova file which was several gigs as well. OVF           Open Virtualization Format MF             Manifest file VMDK       Virtual Machine Disk OVA           Open Virtualization Appliance The ovf file is a xml file that contains metadata for the ovf package The mf file contains the SHA1 hash codes of all files in the package The vmdk file is the disk image of the virtual machine,  VMware Workstation or VirtualBox. (vmdk format was originally developed by VMware and is an open format now). All of
Read more

SOAPUI - import certificate

Image
Note: SoapUI has two versions, one is open source and second Professional version. The open source can be download here . (confirmed link 12/19/2018). SSL Handshake issue:   There is an Issue in SoapUI version 5.3.0 (and 5.2.0 version) with SSL handshake error. It was resolved by updating below in vmoptions file ( refer here ). However, the error that shows up while trying to load wsdl is "Error loading WSDL" as below The fix is to Enable TLS 1.2 protocol for SOAP/REST calls in SoapUI, by ammending the vmoptions file to add the directive for TLS as (-Dsoapui.https.protocols=TLSv1.2). Refer here . Update: Version 5.5.0 does not have this issue. If you are on 5.3.0 better upgrade to 5.5.0 which is available now (Feb 2019). I had above issue as well as another issue reaching to https endpoint. Upgrade to 5.5.0 resolved issue. Select "Check for updates" under the Help menu and you will get option for upgrade. Select upgrade current version and accept all defaul
Read more

Session Timeout in Oracle Access Manager

Image
Session Timeout in Oracle Access Manager (OAM) The session lifetime and Idle timeout entries control how long a user's session is valid. In OAM, a user session is an object which represents an authenticated user. This object is stored in the server memory and if Database session persistence is enabled, this object is stored or available in the database. Each session is unique and is identified by both a userid and Session ID (session identifier), see screenshot below "OAM User Session Management".  A valid session means a user has been authenticated with OAM. A session can have following three states: 1) active 2) inactive 3) expired When a session is created it is in active state and is available as an object in the OAM. After a set time - idle timeout, the session moves or transitions to inactive state. And finally after the Session Lifetime time, the session is marked as expired. Expired sessions are removed from server memory. Read more about Session Lifetime
Read more