X

Tips and HowTos for Single Sign-On & Federation Oracle Identity Management Integrations

  • December 4, 2014

Using OAM Pre Authentication Advanced Rules in OIF IdP

Today I will showcase how to use the OAM Authentication Advanced Rule with OIF as an IdP with the following use case:

  • OIF acts as the IdP
  • A specific scheme is used to challenge all the users
  • The OAM Authentication Policy for that scheme is configured to have a Pre-Authentication Advanced Rule that will evaluate if the browser is a desktop browser or a mobile browser
    • If the user is using a desktop/laptop, then the configured Authentication Scheme will be used
    • Otherwise if the user is on a mobile, another scheme targeted for mobile platforms will be used, which will facilitate user interaction by using a mobile login page

For more information about the Pre Authentication Advanced Rules in OAM, refer to the OAM/OIF 11.1.2.2.0 Administrator's Guide

OAM Authentication Advanced Rules


In the 11.1.2.2.0 release of Oracle Access Manager, Advanced Rules for Authentication Policies were introduced:

  • Pre Authentication Rules which allows an administrator to define a policy that will be evaluated when an OAM authentication operation is being performed, before the user is challenged by the Authentication Scheme
    • The rule can either block access
    • Or instruct OAM to use a secondary Authentication Scheme to challenge the user, different than the one listed as the Authentication Scheme in the Authentication Policy
  • Post Authentication rules which allows an administrator to define a policy that will be evaluated after the Authentication Scheme was executed, to block access if necessary.

The runtime data that can be evaluated by the OAM Authentication Advanced Rule is based on either the request, session or user data:

  • Request data: this includes the information sent by the user's browser as well as the protected resource being requested
    • Browser data
      • HTTP headers (User-Agent, Cookie...)
      • Location (IP Address, Proxy address...)
    • Protected resource
      • Hostname
      • Port
      • Path
      • Query String
      • ...
  • Session Data if the rule is a Post Authentication Rule
  • User Data if the rule is a Post Authentication Rule

The OAM Administrator's guide lists the various properties that can be used.

For example, the following Pre Authentication Rule could be used to route authentication requests for Smartphones to another OAM Authentication Scheme:

request.userAgent.lower().find('iphone') > 0 or
request.userAgent.lower().find('mobile') > 0 or
request.userAgent.lower().find('blackberry') > 0 or
request.userAgent.lower().find('android') > 0

In this next example, the Post Authentication Rule indicates to deny access for users having opened more than 2 sessions:

session.count > 2

Note: Post Authentication Rules which are evaluated as Authentication Responses after Authentication are not evaluated in a Federation SSO flow, since OIF/IdP flow does not involve any Authentication Responses. To implement some Authorization based on the user's identity, Token Issuance Policies can be used, as discussed in this article.

Advanced Rules with OIF/IdP


Federation Authentication Policies

When configuring OIF/IdP to use a specific OAM Authentication Scheme to challenge users at runtime, an intermediary OAM Authentication Policy will be created and bound to the specified OAM Authentication Scheme.

In order to apply Authentication Advanced Rules within an IdP flow, we will need to modify those intermediary OAM Authentication Policies managed by the OIF administration modules.

Out of the box, there are four Federation Authentication Policies existing in the IAM Suite Application Domain that are used by OIF/IdP to authenticate a user at runtime:

  • LocalAuthnFederationBasicScheme
  • LocalAuthnFederationBasicFAScheme
  • LocalAuthnFederationLDAPScheme
  • LocalAuthnFederationFAAuthScheme

Additionally, Federation Authentication Policies will be created whenever a new OIF/IdP is configured to use another Authentication Scheme to challenge users during a Federation SSO operation.

The name of the Federation Authentication Policy is based on the Authentication Scheme configured in OIF/IdP: "LocalAuthnFederation" + Name_of_the_Authentication_Scheme.

Those policies should not be modified, except to define Pre and Post Authentication Rules.

Defining an Advanced Rule for a Federation Authentication Policy

To configure an Advanced Rule for a Federation Authentication Policy, perform the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Click Search and select the IAM Suite Application Domain
  • Click on the Authentication Policies tab
  • Click on the Federation Authentication Policy you wish to modify
  • Click on the Advanced Rules tab in that policy
  • Define a pre authentication policy
  • Apply

We will see later an example of those steps.

Federation Authentication Methods

As mentioned in a previous article, it might be required to configure OIF/IdP to map any OAM Authentication Schemes used to challenge users to a Federation Authentication Methods, even the second Authentication Scheme that might be configured in a Pre Authentication Rule.

This is done by using one of the OIF WSLT commands:

  • addSPPartnerProfileAuthnMethod on an SP Partner Profile
  • addSPPartnerAuthnMethod on an SP Partner

Example


In this example, I will configure OIF to:

  • Interact with a remote SP via the SAML 2.0 protocol
  • Have the LDAPScheme as the default Authentication Scheme system wide
  • Have the LocalAuthnFederationLDAPScheme Authentication Policy set up with a Pre Authentication Rule to use the BasicScheme if the client is a Smartphone
  • Map the LDAPScheme to the SAML 2.0 Federation Authentication Method urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  • Map the BasicScheme to the SAML 2.0 Federation Authentication Method urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

Default Scheme for OIF/IdP

First let's configure OIF/IdP to use a default Authentication Scheme (even though that is the default scheme out of the box):

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

The consequence is that the LocalAuthnFederationLDAPScheme OAM Authentication Policy will now be used to challenge users for the remote SP partner.

OAM Advanced Pre Authentication Rule

Let's now create the Pre Authentication Rule that will indicate to OAM to use the BasicScheme for Smartphone users: the rule will be based on the User-Agent HTTP header:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Click Search and select the IAM Suite Application Domain
  • Click on the Authentication Policies tab
  • Click on the LocalAuthnFederationLDAPScheme policy
  • Click on the Advanced Rules tab in that policy
  • Create a new Pre Authentication Rule

Perform the following actions:

  • Enter the information for the pre authentication rule:
    • Rule Name: MobileUsers
    • Condition:
    • request.userAgent.lower().find('iphone') > 0 or request.userAgent.lower().find('mobile') > 0 or request.userAgent.lower().find('blackberry') > 0 or request.userAgent.lower().find('android') > 0
    • Deny Access: unchecked
    • Switch to Authentication Scheme: BasicScheme

Perform the following actions:

  • Click Add
  • Click Apply

Federation Authentication Method Mappings

Finally, let's map the schemes that will be used in our deployments to SAML 2.0 Federation Authentication Methods (even though out of the box the mapping already exists for LDAPScheme and BasicScheme).

In our environment, two schemes are used:

  • LDAPScheme, configured in OIF/IdP
  • BasicScheme, configured in the Pre Authentication Rule

We will map both schemes to urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport at the partner profile level:

  • 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 addSPPartnerProfileAuthnMethod() command:
    addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "LDAPScheme")
    addSPPartnerProfileAuthnMethod("saml20-sp-partner-profile", "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "BasicScheme")
  • Exit the WLST environment:
    exit()

Test


When performing Federation SSO from a desktop/laptop browser, OIF/IdP will challenge with the LDAPScheme and the user will see the following login page:

While a Smartphone user for a Federation SSO operation with the same SP partner would see an HTTP Basic Authentication challenge:

In my next article, I will show how to implement an IdP Discovery Service.
Cheers,
Damien Carru

Join the discussion

Comments ( 12 )
  • guest Thursday, March 31, 2016

    Hey Damian,

    Quick question regarding pre-authentication rules. Do you know how to do a false check and switching schemes?

    What I mean by that is, I have an internal IP address range that I know needs to use the default authentication policy/scheme, but what I want to do is check if the IP address coming in is NOT in that range, and then switch schemes.

    I don't see anything in the official docs about false checks like that. I would like to get something like that working, if possible.

    Second, do you know if in OAM PS3 (11.1.2.3.0), can you have multiple conditions in the rule using an "AND" vs "OR" (like in your example)?

    I have a need to check the federation partnerID as well as the IP address trying to access it, and want to switch schemes based on those conditions.

    Thanks,


  • Aspi Engineer Monday, August 22, 2016

    Hi Damien,

    What language and syntax is used when creating these pre and post auth rules.

    What I mean is that the examples show the following functions being used: lower(), find(), startsWith(), etc. What other functions can be used?

    Is it java, groovy, python? Or is there a fixed set of functions and operators (==, or, and) that can be used.

    Regards

    Aspi


  • guest Monday, October 24, 2016

    Before starting all the great changes your site gives, is there a way to determine the status of the values or way to take make a point in time before all the changes are tried, to revert back to if the changes don't work? or don't work out? and if so what is the process to revert back? Thanks


  • guest Tuesday, October 25, 2016

    Is it possible to customize the basic http login page to add something like "use mobile authentication credentials" if the authentication store is using a different attribute than the default scheme as a user id from it's identity store?


  • guest Wednesday, November 30, 2016

    Hi,

    Regarding the IP negative rule in range, I am not sure it is supported, but you should confirm this with Oracle Support.

    Regarding the multiple conditions, I would expect the "and" to be supported.

    Damien


  • Damien Wednesday, November 30, 2016

    Hi "Aspi",

    You would need to reach out to Oracle Support with this question, to get an accurate response.

    Damien


  • Damien Wednesday, November 30, 2016

    Hi Jethoma,

    You would need to look at the OAM Developer's Guide to customize the login page.

    Damien


  • Damien Wednesday, November 30, 2016

    Hi Jethoma,

    Regarding your status/value/changes question: could you provide more details on the use case you are exercising?

    Damien


  • guest Wednesday, January 25, 2017

    This was a great note to provide new options for us as we move our federation (SAML IdP) into OAM. We can select authentication scheme based on the origin of the user, which is great.

    However one thing I can't quite figure out is how to implement access restrictions based on the origin of the user (client IP). The token issuance policy is limited to identity information (user/group from an identity store), so presumably this would need to be handled via an authorization policy. But considering authentication scheme for federation/SAML resources is handled through WLST commands like setIdPDefaultScheme rather than the console, I'm not sure what's the right way to do authorization. I see authorization policies in the IAM Suite application domain in the console, but there's no setting for applying an authorization scheme to a token resource. Does this involve using the authzPolicy argument to some other WLST command? If so how is it expected to be used? Tied to the authentication scheme command? It's really not clear from the info I'm seeing.

    The goal here being that IP-based authn scheme is great, but for any services which are intended to be used only by users on our network, if you already have an OAM session, presumably the authn scheme never comes into play. In which case controlling or even restricting the ability to authenticate for a given SP by pre-authentication presumably never gets triggered, so restricting access via authz then becomes necessary.

    Thanks,

    Stephen


  • Damien Monday, February 6, 2017

    Hi,

    You are correct in the sense that you can't use an authorization policy in this context: only a Token Issuance Policy is available when evaluating authorization during Federation SSO, with OAM/OIF acting as an IdP, and AFAIK, there are no conditions based on origin of the user.

    I would suggest you to contact your Oracle Support rep and ask to review this use and perhaps request an enhancement.

    Regards,

    Damien


  • Stephen Tuesday, February 28, 2017

    BTW, looking back at that first question, I was just trying to figure that out myself, and right now it's looking like just adding a "not" in front of whatever condition will negate it. So "not location.clientIP in ['xxx']" appears to be the opposite of the "location.clientIP in ['xxx']" condition.

    So far that seems to be working for some simple test cases at least. If it holds true hopefully this helps other people. The OAM info on the conditions doesn't say anything at all about this, and almost nothing on the other booleans.

    Stephen


  • Damien Thursday, March 2, 2017

    Hi Stephen,

    Good catch. I agree with you that the OAM documentation is rather light on the conditions.

    Thanks for sharing!

    Damien


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.