Partner Profiles in OIF

In this article, I will discuss about the concept of Partner Profile in the OIF configuration.

During any Federation runtime operation between OIF (as an IdP or SP) and remote partners, numerous configuration properties are evaluated that will affect how OIF will execute the operation.

Some of the configuration parameters driving the protocol exchange are specific to the partner with which OIF is interacting (like how the NameID should be populated if OIF acts as a SAML 2.0 IdP), while others can be common to a group of partners (like whether or not to sign SAML 2.0 Assertions when OIF acts as an IdP).

Instead of having each partner entry in the OIF configuration containing all the OIF parameters required to perform the Federation runtime operations, OIF makes use of a Partner Profile which:

  • Contains a set of settings that are common to all partners referencing that partner profile
  • Is specific to
    • A type, either IdP or SP
    • A protocol: SAML 2.0, SAML 1.1 or OpenID 2.0

A Partner Profile in OIF typically contains configuration settings that are generally not changed often and that are considered advanced. For the day-to-day operations, the administration capabilities provided in the OAM Administration Console or via the OIF WLST commands are enough for most cases.

For advanced cases requiring configuration changes, an administrator would have the choice to:

  • Either update the Partner configuration entry, so changes would only apply to the partner
  • Or update the Partner Profile entry, so changes would apply to all partners bound to the Partner Profile

Important note: given the advanced nature of the configuration, Partner Profiles can only be managed via OIF WLST commands.

Default Partner Profiles


Out of the box, OIF defines default Partner Profiles which contain the default settings for their respective Federation protocols and service types. The default settings are tailored for the common use cases encountered in production deployments today, and as such you would not need to change those except for specific use cases.

After installation, the following Partner Profiles will be defined in the OIF configuration:

  • saml20-idp-partner-profile:
    • Protocol: SAML 2.0
    • Type: Partner Profile for IdP partners
  • saml20-sp-partner-profile:
    • Protocol: SAML 2.0
    • Type: Partner Profile for SP partners
  • saml11-idp-partner-profile:
    • Protocol: SAML 1.1
    • Type: Partner Profile for IdP partners
  • saml11-sp-partner-profile:
    • Protocol: SAML 1.1
    • Type: Partner Profile for SP partners
  • openid20-idp-partner-profile:
    • Protocol: OpenID 2.0
    • Type: Partner Profile for IdP/OP partners
  • openid20-sp-partner-profile:
    • Protocol: OpenID 2.0
    • Type: Partner Profile for SP/RP partners

WLST Commands


Settings contained in a Partner Profile entry are deemed advanced properties, and as such as only manageable via OIF WLST commands, while basic settings changes or day-to-day operations can be performed either via the OAM Administration Console or via OIF WLST commands.

In the next sections, I will show how to use the various OIF WLST Partner Profile commands to:

  • List all the Partner Profiles
  • List the Partners bound to a specific Partner Profile
  • List the Partner Profile used by a Partner
  • Display the content of a Partner Profile
  • Create a new Partner Profile
  • Update a Partner Profile: in this case I will change the hashing algorithm used in Digital Signatures in outgoing signed messages to SHA-256
  • Bind the Partner Profile to a Partner
  • Delete a Partner Profile

It is sometimes desirable to create new Partner Profile entries when several partners have a common set of use cases which differ from the configuration defined in the Partner Profile entry they are bound to. Instead of having each Partner override a setting (for example signing messages using SHA-256 digest algorithm instead of the default SHA-1 defined in their Partner Profile entries), the better approach consists in:

  • Creating a new Partner Profile by making a copy of the Partner Profile currently used by the Partner
  • Set the Partner to use the new Partner Profile
  • Modify the Partner Profile

For more information on the OIF WLST commands, please refer to the Oracle documentation.

WLST Environment

I will assume that you are already in the WLST environment and connected using:

  • 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()

Listing Partner Profiles

The listFedPartnerProfiles() WLST command will list all Partner Profiles currently present in OIF, and will display:

  • Name
  • Type (SP or IdP)
  • Protocol Version: SAML 2.0, SAML 1.1 or OpenID 2.0

For example, an execution of the command would display the following:

wls:/test_domain/domainRuntime> listFedPartnerProfiles()
Partner Profile ID  |  Type  |  Protocol Version
saml20-sp-partner-profile  |  sp  |  saml20
saml20-idp-partner-profile  |  idp  |  saml20
saml11-sp-partner-profile  |  sp  |  saml11
saml11-idp-partner-profile  |  idp  |  saml11
openid20-sp-partner-profile  |  sp  |  openid20
openid20-idp-partner-profile  |  idp  |  openid20

Listing Partners for a Specific Partner Profile

The listFedPartnersForProfile() command will list all partners bound to the Partner Profile specified as a parameter.

Executing the command to display all partners referencing the saml20-sp-partner-profile Partner Profile (which is the default OOTB profile for SAML 2.0 SP Partners) would display the following:

wls:/test_domain/domainRuntime> listFedPartnersForProfile("saml20-sp-partner-profile")
adc00peq
Office365
ACME-ADFS

Listing Partner Profile for a Specific Partner

The getFedPartnerProfile() command will display the Partner Profile used by the Partner and the partner type specified as parameters (the partner type is either idp or sp)

Executing the command to display the Partner Profile referenced by the ACME-ADFS SP Partner would display the following:

wls:/test_domain/domainRuntime> getFedPartnerProfile("ACME-ADFS", "sp")
saml20-sp-partner-profile

Displaying the Content of a Partner Profile

The displayFedPartnerProfile() WLST command will display on the command line the settings defined in the entry specified as a parameter.

Executing the command to show the Partner Profile would display the following:

wls:/test_domain/domainRuntime> displayFedPartnerProfile("saml20-sp-partner-profile")
includecertinsignature=0
nameidqualifier=
forceconsent=0
authnmethodmappings={urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aac%3Aclasses%3APasswordProtectedTransport=LDAPScheme-1,OAM10gScheme-0,FAAuthScheme-1,BasicScheme-1,BasicFAScheme-1}
sendsignedrequestquery=1
forceconsenturl=
sendencryptednameid=0
sendsignedresponsequery=1
setconsentenabled=0
sessionattributeforceauthn=0
defaultauthnrequestnameidformat=orafed-emailaddress
version=saml20
requesttimeout=2000
audiencerestrictionenabled=1
setconsentvalue=
sendsignedresponsesoap=1
allowfederationcreation=1
sendsignedresponseassertionpost=0
reauthenticate=3600
description=
sendattribute=1
defaultencryptionmethod=http://www.w3.org/2001/04/xmlenc#aes128-cbc
requiresignedrequestquery=0
requiresignedresponsepost=0
audiencerestrictionvalue=
sendsignedrequestsoap=1
sendsignedrequestpost=1
sendencryptedattribute=0
partnerprofiletype=sp
requiresignedresponsesoap=0
requiresignedrequestpost=0
requiresignedresponsequery=0
partnerprofileid=saml20-sp-partner-profile
sendsignedresponsepost=1
requiresignedrequestsoap=0
sendsignedassertion=1
sendsignedresponseassertionsoap=0
assertionvalidityinterval=300

Creating a new Partner Profile

In this section, I will show how to create a new Partner Profile from an existing one, by using the createFedPartnerProfileFrom() method which takes as arguments:

  • The name of the new Partner Profile
  • The name of the Partner Profile to copy from

Executing the command to create a new SAML 2.0 SP Partner Profile based on the OOTB one would display the following:

wls:/test_domain/domainRuntime> createFedPartnerProfileFrom("new-saml20-pp", "saml20-sp-partner-profile")
Command was successful.

Updating a Partner Profile

In this section, I will show an example of a WLST configuration change command involving a Partner Profile. As mentioned previously, I created this Partner Profile for Partners for which SHA-256 needs to be used in outgoing Digital Signatures. I will use the configureFedDigitalSignature() command to configure the new Partner Profile called  new-saml20-pp to use SHA-256.

The command takes the Partner Profile name, the profile type as well as the hashing algorithm to use as parameters:

wls:/test_domain/domainRuntime> configureFedDigitalSignature(partnerProfile="new-saml20-pp", partnerType="sp", algorithm="SHA-256")
Command was successful.

Binding a Partner to a Partner Profile

Once the new Partner Profile is created (and configured) existing Partners can be bound to it.

In my example, three SP Partners are listed:

  • adc00peq
  • Office365
  • ACME-ADFS

I only want adc00peq and ACME-ADFS to be switched to the new Partner Profile. I will use the setFedPartnerProfile() command and specify the Partner, its type and the new Partner Profile to use:

wls:/test_domain/domainRuntime> setFedPartnerProfile("adc00peq", "sp", "new-saml20-pp")
Command was successful.
wls:/test_domain/domainRuntime> setFedPartnerProfile("ACME-ADFS", "sp", "new-saml20-pp")
Command was successful.

Listing the partners bound to the new profile would show adc00peq and ACME-ADFS, while listing the partners to the saml20-sp-partner-profile profile would only show Office365:

wls:/test_domain/domainRuntime> listFedPartnersForProfile("new-saml20-pp")
adc00peq
ACME-ADFS
wls:/test_domain/domainRuntime> listFedPartnersForProfile("saml20-sp-partner-profile")
Office365

In the example, OIF/IdP would now sign using the SHA-256 digest algorithm for adc00peq and ACME-ADFS, while it would still use SHA-1 for the Office365

Deleting a Partner Profile

Partner Profiles can be deleted via the deleteFedPartnerProfile() which takes the name of the profile as a parameter, but prior executing the command, you must ensure that no Partner entries are currently bound to this Partner Profile.

If I attempt to delete the new-saml20-pp Partner Profile while it is still referenced by the adc00peq and ACME-ADFS SP Partners, the method will return an error:

wls:/test_domain/domainRuntime> deleteFedPartnerProfile("new-saml20-pp")
The Federation Partner Profile is in use by a Partner

First, the two partners will need to be switched back to another Partner Profile (saml20-sp-partner-profile in this example), and then the deleteFedPartnerProfile() can be invoked:

wls:/test_domain/domainRuntime> setFedPartnerProfile("adc00peq", "sp", "saml20-sp-partner-profile")
Command was successful.
wls:/test_domain/domainRuntime> setFedPartnerProfile("ACME-ADFS", "sp", "saml20-sp-partner-profile")
Command was successful.
wls:/test_domain/domainRuntime> deleteFedPartnerProfile("new-saml20-pp")
Command was successful.

In the next article, I will discuss about authentication when OIF acts as an IdP and how the server can be configured to use specific OAM Authentication Schemes to challenge the user.
Cheers,
Damien Carru

Comments:

Thanks for the valuable information !

Posted by guest on June 30, 2014 at 08:03 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
« April 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today