Integrating ADFS 2.0/3.0 IdP with OIF SP

As a continuation of my previous article, I will today describe how to integrate ADFS 2.0/3.0 as an IdP and OIF as an SP.

Be sure to have read my previous entry covering the pre-requisites.

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.

ADFS Setup


To add OIF as an SP in ADFS IdP, perform execute the following steps:

  • Go to the machine where ADFS 2.0 is deployed
  • If ADFS 2.0 is used
    • Click Start Menu -> Programs -> Administrative Tools -> AD FS 2.0 Management
    • Expand ADFS 2.0 -> Trust Relationships
  • If ADFS 3.0 is used
    • In Server Manager, click Tools -> AD FS Management
    • Expand AD FS -> Trust Relationships
  • Right click on Relying Party Trusts and select Add Relying Party Trust
  • The Add Relying Party Trust window will appear

Execute the following steps:

  • Click Start
  • Select Import data about the relying party from a file
  • Click browse and select the OIF SP SAML 2.0 Metadata file from the local machine (it is required for the OIF endpoints to be SSL terminated, otherwise ADFS will not import the metadata. See my previous pre-requisites article about SSL)

Execute the following steps:

  • Click Next
  • Enter a name for the new OIF SAML 2.0 Service Provider

If using ADFS 3.0, execute the following steps:

  • Click Next
  • The next screen will show an optional multi factor authentication settings section
  • Select the option depending on your requirements

Execute the following steps:

  • Click Next
  • Select Permit all users to access this Relying Party

Execute the following steps:

  • Click Next
  • A summary window will be displayed

Execute the following steps:

  • Click Next
  • Leave Open the Edit Claims box checked

Execute the following steps:

  • Click Close
  • The Edit Rule window will appear

Execute the following steps:

  • Click Add Rule: we will configure ADFS to retrieve the user’s email address from LDAP and include it as EmailAddress SAML Attribute
  • Select Send LDAP Attributes as Claims

Execute the following steps:

  • Click Next
  • Enter a name for the Claim Rule
  • Select Active Directory as the Attribute Store
  • Since we are using Email Address as the NameID, in the first row, select Email Addresses as the LDAP Attribute, and Email Address as the Outgoing Claim Type

Execute the following steps:

  • Click Finish
  • The list of rules will be displayed

Execute the following steps:

  • Click Add Rule: we will transform the SAML Attribute EmailAddress to make it the NameID with its format set to email address.
  • Select Transform an Incoming Claim

Execute the following steps:

  • Click Next
  • Enter a name for the rule
  • Select Email Address as the Incoming Claim Type
  • Select NameID as the Outgoing Claim Type
  • Select Email as the Outgoing name ID format
  • Select Pass through all claim values

Execute the following steps:

  • Click Finish
  • The list of claim rules will be displayed
  • Click OK

As mentioned in the pre-requisites article, if you want to configure ADFS to use/accept SHA-1 signatures, perform the following steps (Note: if you don’t configure ADFS to use/accept SHA-1 signatures, you will have to configure OIF to use SHA-256 for signatures):

  • Go to the machine where ADFS is deployed
  • If ADFS 2.0 is used
    • Click Start Menu -> Programs -> Administrative Tools -> AD FS 2.0 Management
    • Expand ADFS 2.0 -> Trust Relationships
  • If ADFS 3.0 is used
    • In Server Manager, click Tools -> AD FS Management
    • Expand AD FS -> Trust Relationships
  • Right click on the newly created Relying Party and select Properties
  • Select the Advanced Tab
  • Select SHA-1
  • Click OK

As also mentioned in the pre-requisites article, if you decided to disabled decryption on the ADFS IdP, execute the following steps:

  • Go to the machine where ADFS is deployed
  • If ADFS 2.0 is used, click Start Menu -> Programs -> 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
    • For example:
      set-ADFSRelyingPartyTrust –TargetName "ACME SP" –EncryptClaims $False

OIF Setup


To add ADFS as an IdP partner in OIF, execute the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Identity Federation -> Service Provider Administration
  • Click on the “Create Identity Provider Partner” button
  • In the Create screen:
    • Enter a name for the partner
    • Check whether or not this partner should be used as the IdP by default when starting a Federation SSO operation, if no IdP partner is specified. (in this example we will set it as the default IdP)
    • Select SAML 2.0 as the Protocol
    • Click Load Metadata and upload the SAML 2.0 Metadata file for the IdP
    • Assertion Mapping section:
      • Optionally set the OAM Identity Store that should be used (note: in the example, I left the field blank to use the default OAM Identity Store)
      • Optionally set the user search base DN (note: in the example, I left the field blank to use the user search base DN configured in the Identity Store)
      • Select how the mapping will occur (note: in the example, I am mapping the Assertion via the NameID to the LDAP mail attribute)
    • Select the Attribute Profile that will be used to map the names of the attributes in the incoming SAML Assertion to local names. See my next article on IdP Attribute Profile for more information. In this example, I will use the default IdP Attribute Profile.
    • Click Save

As mentioned in the pre-requisites article, if you want to configure OIF to use SHA-256 for signatures, perform the following steps (Note: if you don’t configure OIF to use SHA-256 for signatures, you will have to configure ADFS to use/accept SHA-1 signatures):

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()
  • Execute the configureFedDigitalSignature() command:
    configureFedDigitalSignature(partner="PARTNER_NAME", partnerType="idp/sp", algorithm="SHA-256/SHA-1")
    • Replace PARTNER_NAME with the name of the partner added
    • Set the partnerType to idp or sp
    • Set the algorithm to SHA-256 or SHA-1
    • An example would be:
      configureFedDigitalSignature(partner="ADFSIdP", partnerType="idp", algorithm="SHA-256")
  • Exit the WLST environment:
    exit()

As also mentioned in the pre-requisites article, if you decided not to disable strong encryption on the ADFS IdP, be sure that the JCE Unlimited Strength Jurisdiction policy files were installed in the OIF environment.

Test


To test the integration:

  • Either protect a resource with WebGate and a FederationScheme with ADFS IdP being the Default SSO Identity Provider for OIF
  • Or use the OIF Test SP application and select ADFS as the IdP


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



Comments:

The last image in the blog entry is broken.

https://blogs.oracle.com/dcarru/resource/Art12-ADFSIdP-OIFSP/Art12-snap0174.jpg

Posted by Markus Zellner on August 12, 2014 at 02:33 AM EDT #

It is now fixed.

Thanks Markus,
Damien

Posted by Damien on August 12, 2014 at 09:54 AM EDT #

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
« May 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
29
30
31
      
Today