Authentication in OIF / IdP

In this 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.

When OIF 11gR1 acting as an IdP and OAM 11g were integrated together, OIF was delegating the user authentication to OAM via the use of WebGate:

  • OHS had to be installed in and configured to act as a reverse HTTP proxy for OIF
  • WebGate had to be installed on OHS and registered with OAM
  • OAM had to be configured to protect an OIF URL with
    • An Authentication Policy
    • An Authorization Policy
  • Set up the OIF logout URL in OAM
  • OIF had to be configured to use the OAM 11g Authentication Engine
    • Enter the HTTP header containing the userID injected by WebGate
    • Set up the OAM logout URL

In OIF 11gR2 and OAM 11gR2, the two components are tightly integrated together:

  • No initial setup is required to integrate the two products
  • No WebGate/OHS is required for IdP authentication
  • OIF/IdP can leverage any OAM Authentication Scheme

Note: given the advanced nature of the configuration, OIF authentication setup can only be managed via OIF WLST commands.

Enjoy the reading!

Overview


In the 11.1.2.2.0 or later release of OAM/OIF, the OIF J2EE Web Application and the OAM J2EE Web Application are contained in the same OAM J2EE EAR Application which is deployed in a standalone WLS instance.

This deployment approach allows the two modules to internally forward the incoming user’s HTTP request from OIF to OAM and vice versa. This allows the OIF/IdP application to trigger a local OAM authentication operation that will challenge and identify the user.

At runtime, when authentication is required by OIF/IdP in a Federation operation, OIF/IdP will:

  • Internally forward the user to OAM
  • Indicate to OAM which Authentication Scheme to use for user authentication
  • OAM will determine if a user needs to be challenged:
    • If the user is not authenticated yet
    • If the user is authenticated but the session timed out
    • If the user is authenticated, but the authentication scheme level of the original authentication is lower than the level of the authentication scheme requested by OIF/IdP
  • If the user needs to be challenged, OAM will do so based on the rules of the authentication scheme specified by OIF/IdP
  • Once OAM has (optionally) authenticated the user and created a session, it will internally forward the user back to OIF/IdP with identity and session information
  • OIF/IdP will resume the Federation operation it was performing
Out of the box, OIF/IdP is configured to use the LDAPScheme as the OAM Authentication Scheme to challenge and identify users: this is set as the default global scheme for OIF/IdP.

It is possible for an administrator:

  • To set the global default OAM Authentication Scheme to be used to authenticate users.
  • On an SP Partner Profile to set the OAM Authentication Scheme to be used to authenticate users for SP partners bound to this SP Partner Profile. If defined, this setting will take precedence over the global default OAM Authentication Scheme
  • On an SP Partner to set the default OAM Authentication Scheme to be used to authenticate users for this SP partner. If defined, this setting will take precedence over the OAM Authentication Scheme defined in the SP Partner Profile referenced by this SP Partner or will take precedence over the global default OAM Authentication Scheme

Testing Setup


In this article, I will use the following testing environment:

  • OIF/IdP
  • One SAML 2.0 SP Partner called AcmeSP
  • Another SAML 2.0 SP Partner called HRsp

I will execute several test cases:

  • Global Default Authentication:
    • Both AcmeSP and HRsp will use the default SAML 2.0 SP Partner Profile
    • No Authentication Scheme will be set at the SP Partner level
    • No Authentication Scheme will be set at the SP Partner Profile level
    • The global default authentication will be used as is (OOTB: LDAPScheme), and a Federation SSO operation will be performed
    • The global default authentication will be set to BasicScheme (HTTP Basic Authentication), and a Federation SSO operation will be performed
  • SP Partner Profile Authentication
    • AcmeSP will use the default SAML 2.0 SP Partner Profile
    • HRsp will use the another SAML 2.0 SP Partner Profile
    • No Authentication Scheme will be set at the SP Partner level
    • No Authentication Scheme will be set at the default SAML 2.0 SP Partner Profile level, but the new SAML 2.0 SP Partner Profile will be configured to use BasicScheme
    • The global default authentication will be set to LDAPScheme
    • A Federation SSO will be performed with AcmeSP
    • A Federation SSO will be performed with HRsp
  • SP Partner Authentication
    • Both AcmeSP and HRsp will use the default SAML 2.0 SP Partner Profile
    • The Authentication Scheme for the default SAML 2.0 SP Partner Profile will be set to BasicScheme
    • The Authentication Scheme for the AcmeSP will be set to LDAPScheme
    • The global default authentication will be set to LDAPScheme
    • A Federation SSO will be performed with AcmeSP
    • A Federation SSO will be performed with HRsp
  • Step up Authentication via different Authentication Levels
    • Both AcmeSP and HRsp will use the default SAML 2.0 SP Partner Profile
    • The Authentication Scheme for the default SAML 2.0 SP Partner Profile will be set to BasicScheme
    • The Authentication Scheme for the AcmeSP will be set to LDAPScheme
    • The global default authentication will be set to LDAPScheme
    • LDAPScheme will be configured to have its level set to 3
    • BasicScheme will be left unchanged with its level set to 2
    • Test #1:
      • Federation SSO will be performed with AcmeSP
      • User is challenged via LDAPScheme
      • In the same browser, Federation SSO will be performed with HRsp
      • The user won’t be challenged
    • Test #2:
      • Federation SSO will be performed with HRsp
      • User is challenged via BasicScheme
      • In the same browser, Federation SSO will be performed with AcmeSP
      • User will be challenged via LDAPScheme

The following sections, each one describing a test case, will be in a chronological order, with each section starting where the previous section left off.

Note: If HTTP Basic Authentication will be used at the IdP, the WebLogic domain where OAM/OIF are running needs to be configured to not validate the HTTP Basic Authentication for unsecured resources.

HTTP Basic Authentication

By default, if a browser sends HTTP Basic Authentication credentials to OAM, the WLS server will attempt to validate those before letting OAM process the request: this can result in authentication failures, particularly if the WLS domain was not configured with WLS LDAP Authenticators for each Identity Store created in OAM.

Note: even if the WLS domain was configured correctly to have a WLS LDAP Authenticator for each Identity Store created in OAM, this will result in two authentication operations, one by WLS, and the other one required by OAM to create an OAM session.

It is possible to disable the automatic validation of HTTP Basic Authentication credentials sent to unsecured applications in the WLS domain where OAM is running. See section “Understanding BASIC Authentication with Unsecured Resources” of the Oracle Fusion Middleware Programming Security for Oracle WebLogic Server guide for more information.

To disable the automatic validation of HTTP Basic Authentication credentials sent to unsecured applications in the WLS domain, execute the following steps:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Start an edit session:
    edit()
    startEdit()
  • Navigate to the SecurityConfiguration node:
    cd('SecurityConfiguration')
  • Navigate to the domain (replace DOMAIN_NAME with the name of the WLS domain where OAM is installed):
    cd('DOMAIN_NAME')  
  • Set the EnforceValidBasicAuthCredentials setting to false to disable tomatic validation of HTTP Basic Authentication credentials sent to unsecured applications:
    set('EnforceValidBasicAuthCredentials','false')
  • Save and activate the changes:
    save()
    activate()
  • Restart the servers in the WLS domain for the changes to take effect

Global Default Authentication


The first step will be to create and configure SP Partners in OIF/IdP for SAML 2.0 SSO. After having set that up (see previous articles on how to do that), the list of SP Partners in OIF/IdP would look like:

Performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user using the default global Authentication Scheme configured to be LDAPScheme OOTB:

To switch the default global Authentication Scheme to BasicScheme, I will use the OIF WLST setIdPDefaultScheme() command and specify which scheme to be used as the default:

  • 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 setIdPDefaultScheme() command:
    setIdPDefaultScheme("BasicScheme")
  • Exit the WLST environment:
    exit()

Performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will now result in the OIF/OAM server challenging the user using the OAM BasicScheme instead of LDAPScheme:

To switch back the default global Authentication Scheme to LDAPScheme, perform the following operations:

  • 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 setIdPDefaultScheme() command :
    setIdPDefaultScheme("LDAPScheme")
  • Exit the WLST environment:
    exit()

Performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the LDAPScheme.

SP Partner Profile Authentication


From the previous test cases, the setup is as:

  • AcmeSP and HRsp exist in OIF/IdP
  • The default global Authentication Scheme in OIF/IdP is LDAPScheme
  • Both AcmeSP and HRsp are using the default SAML 2.0 SP Partner Profile

To configure HRsp to use a new SP Partner Profile, execute the following commands (see my previous article in Partner Profiles for more information):

  • 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()
  • Create the new SP Partner Profile from the default SAML 2.0 SP Partner Profile:
    createFedPartnerProfileFrom("new-saml20-pp", "saml20-sp-partner-profile")
  • Bind HRsp Partner to the new SP Partner Profile:
    setFedPartnerProfile("HRsp", "sp", "new-saml20-pp")
  • Exit the WLST environment:
    exit()

At this point, performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the LDAPScheme.

To configure the new SP Partner Profile to have BasicScheme as the default Authentication Scheme, I will use the OIF WLST setSPPartnerProfileDefaultScheme() command:

  • 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()
  • Set the default Authentication Scheme for the new SP Partner Profile to BasicScheme:
    setSPPartnerProfileDefaultScheme("new-saml20-pp", "BasicScheme")
  • Exit the WLST environment:
    exit()

Now, performing Federation SSO with:

  • AcmeSP will result in OIF/IdP challenging the user via the LDAPScheme.
  • HRsp will result in OIF/IdP challenging the user via the BasicScheme.

I will now bind HRsp back to the default SP Partner Profile, and then delete the SP Partner Profile I created in this test:

  • 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()
  • Bind HRsp Partner to the default SP Partner Profile:
    setFedPartnerProfile("HRsp", "sp", "saml20-sp-partner-profile")
  • Delete the new SP Partner Profile:
    deleteFedPartnerProfile("new-saml20-pp")
  • Exit the WLST environment:
    exit()

After executing those commands, performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the LDAPScheme.

SP Partner Authentication


From the previous test cases, the setup is as:

  • AcmeSP and HRsp exist in OIF/IdP
  • The default global Authentication Scheme in OIF/IdP is LDAPScheme
  • Both AcmeSP and HRsp are using the default SAML 2.0 SP Partner Profile

To configure the default SAML 2.0 SP Partner Profile to use BasicScheme as the Authentication Scheme, perform the following operations:

  • 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()
  • Set the default Authentication Scheme for the new SP Partner Profile to BasicScheme:
    setSPPartnerProfileDefaultScheme("saml20-sp-partner-profile", "BasicScheme")
  • Exit the WLST environment:
    exit()

At this point, performing Federation SSO involving either of those AcmeSP or HRsp with OIF/IdP will result in the OIF/OAM server challenging the user via the BasicScheme.

To configure the AcmeSP SP Partner to have LDAPScheme as the default Authentication Scheme, I will use the OIF WLST setSPPartnerDefaultScheme() command:

  • 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()
  • Set the default Authentication Scheme for the AcmeSP SP Partner to LDAPScheme:
    setSPPartnerDefaultScheme("AcmeSP", "LDAPScheme")
  • Exit the WLST environment:
    exit()

Now, performing Federation SSO with:

  • AcmeSP will result in OIF/IdP challenging the user via the LDAPScheme.
  • HRsp will result in OIF/IdP challenging the user via the BasicScheme.

Step Up Authentication via Different Authn Levels


From the previous test cases, the setup is as:

  • AcmeSP and HRsp exist in OIF/IdP
  • The default global Authentication Scheme in OIF/IdP is LDAPScheme
  • Both AcmeSP and HRsp are using the default SAML 2.0 SP Partner Profile
  • The default SAML 2.0 SP Partner Profile is configured with the default Authentication Scheme set to BasicScheme
  • The AcmeSP SP Partner is configured with the default Authentication Scheme set to LDAPScheme

At this point, performing Federation SSO with:

  • AcmeSP will result in OIF/IdP challenging the user via the LDAPScheme.
  • HRsp will result in OIF/IdP challenging the user via the BasicScheme.

OOTB, the Authentication Level for both LDAPScheme and BasicScheme is set to 2. To change the Authentication Level of the LDAPScheme to 3, perform the following operations:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Authentication Schemes
  • Click Search and select LDAPScheme
  • Set the Authentication Level to 3
  • Apply

After those changes, if the user is already authenticated at OAM and that the user performs a Federation SSO operation with OIF/IdP, OIF/OAM will ensure that the scheme which was used to authenticate the user in the first place has a level higher or equal to the scheme configured for the current SP Partner with which Federation SSO is exercised.

For example:

  • If the user is first authenticated via LDAPScheme, it won’t be re-challenged when a second Federation SSO operation is performed with the default Authentication Scheme for that second flow being BasicScheme:
    • Federation SSO is started with AcmeSP Partner
    • User is challenged by OAM/OIF via LDAPScheme
    • OIF/IdP issues an Assertion and redirects the user to AcmeSP
    • In the same browser, Federation SSO is started with HRsp
    • OAM/OIF won’t challenge the user, because the user is already authenticated, the session hasn’t timed out and the level of the scheme used to create the session (which was 3 for LDAPScheme) is higher or equal than the default scheme configured for this current Federation SSO (which is 2 for BasicScheme)
    • OIF/IdP issues an Assertion and redirects the user to HRsp
  • If the user is first authenticated via BasicScheme, it will be re-challenged when a second Federation SSO operation is performed with the default Authentication Scheme for that second flow being LDAPScheme:
    • Federation SSO is started with HRsp Partner
    • User is challenged by OAM/OIF via BasicScheme
    • OIF/IdP issues an Assertion and redirects the user to HRsp
    • In the same browser, Federation SSO is started with AcmeSP
    • OAM/OIF will challenge the user, because the user is already authenticated, the session hasn’t timed out but the level of the scheme used to create the session (which was 2 for BasicScheme) is lower than the default scheme configured for this current Federation SSO (which is 3 for LDAPScheme)
    • OIF/IdP issues an Assertion and redirects the user to AcmeSP

In the next article, I will discuss how OIF/IdP can be configured to map Federation Authentication Methods to OAM Authentication Schemes, both when processing an Authn Request (SP requests a specific Federation Authentication Method) and when sending an Assertion (IdP sets the Federation Authentication Method).
Cheers,
Damien Carru

Comments:

HI, It was a nice reading. By default in OAMPS2, any sp partner created from the admin console is using IDMSuiteAgent Application domain, Can we change this to a a different domain. In our current environment OAM11gr2ps2 we are using OHS 11g webgate and will require OHS to do reverse proxy for all the requests of OIF.

Posted by sameera palnati on May 19, 2014 at 01:40 PM EDT #

You can change the Application Domain / HostID used via the OIF WLST commands, via the appDomain and hostID parameters (see the documentation for setIdPDefaultScheme/setSPPartnerDefaultScheme/setSPPartnerProfileDefaultScheme

But there is no need to change those, as the OIF-IdP/OAM integration leverages the OAM policy components (resources, authentication policies...) for IdP authentication but the URLs used by the user's browser to access OIF/IdP are not taken into account (internal URLs not referencing the hostname where OAM/OIF are installed are used by OIF/IdP to trigger an authentication in OAM).

So the authentication in OIF-IdP/OAM will not be affected when OIF & OAM become fronted by OHS. The /oamfed/* URLs will only need to be set as excluded for that WebGate/Application Domain

Posted by Damien on May 19, 2014 at 04:13 PM EDT #

Many thanks for this valuable and clear information.
These kind of information I expect to find in the official documentation.
I can't understand why we need to rely on fantastics blogs like this.

Posted by guest on May 21, 2014 at 11:35 AM EDT #

Damien,

it is possible to user x509 authentication schema with OIF?

Posted by guest on September 30, 2014 at 05:08 PM EDT #

Damien,

In my particular case the SP is a jboss application. I know that jboss can act like a SP and consume SAML assertion using a specific JAAS Login Module. Have you seen something similar to this setup?

I will also have to forward to the SP ( (jboss application) after successful authentication a assertion with the authenticated userid and list of roles (ldap groups). What I have to do in the IdP (OIF) side to achieve this setup?

Posted by Alexandre Viana on September 30, 2014 at 05:16 PM EDT #

Yes, the X509 Authentication Scheme can be used to challenge/authenticate a user.

Damien

Posted by Damien on October 07, 2014 at 05:38 PM EDT #

Hi,

I never used JBoss as an SP, but it should work with OIF.

Regarding the attributes, you would need to configure OIF/IdP to send the required information by setting up an SP Attribute Profile and binding the SP Partner to that new SP Attribute Profile.

Take a look at my previous articles on "Sending Attributes with OIF/ IdP"

Damien

Posted by Damien on October 07, 2014 at 05:40 PM EDT #

Damien,

i did the setup of oif as IdP and jboss as SP. After call jboss sp i am redirected to oif login page but when oif redirects to jboss a exception is fired at jboss side complaining about dsig:Signature parser error. using firefox saml trace add-on i can see the salm response generated by OIF with status = success. I opened a SR at jboss.

Can i disable the signature of saml responses at OIF side? If it is possible I could implement a simpler integration test with jboss.

Posted by guest on October 07, 2014 at 05:52 PM EDT #

Hi,

With respect to disabling signatures for SAML assertions/messages in Federation SSO flows, this should only be done temporarily for testing purposes, as the proof of authenticity is no longer ensured by the digital signatures (and anybody could create a SAML Assertion and impersonate the IdP). Disabling signatures altogether should only been performed:
- in testing environments
- preferably when the testing environments are not available on the internet to reduce the potential for attacks

To disable signatures for various messages, take a look at my article titled "Crypto Settings in OIF"

Damien

Posted by Damien on October 10, 2014 at 01:39 PM 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