Authorization in OIF / IdP

In this article, I will show how to enable and implement Authorization Policies for Federation SSO when OIF is acting as an IdP.

When OIF authenticates a user on behalf of remote SAML / OpenID 2.0 partners, it will issue a token (SAML or OpenID) containing information about the user that the partner will consume to identify the user. As a part of the creation of the token, OIF/IdP can be configured to evaluate a Token Issuance Policy that will indicate if the user is allowed to perform Federation SSO with that particular SP/RP.

The Token Issuance Policy will be constructed with:

  • The SP Partner Name as the resource
  • One or more constraints
    • The true constraint which is used to indicate that OIF/IdP should issue tokens for all users for the SP partners listed in the policy
    • The Identity constraint made of
      • List of users: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to that list
      • Or list of groups: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to a group listed in the constraint

Enjoy the reading!

Enabling / Disabling Authorization in OIF/IdP


Out of the box, Authorization is disabled in OIF/IdP. As such there is no Authorization enforcement when OIF issues a SAML/OpenID token.

Note: once authorization is enabled, all IdP Federation SSO operations will require a successful authorization policy evaluation. So if you have existing Federation agreements, no Token Issuance Policy and that you enable authorization, the Federation SSO operation will fail until the required Token Issuance Policies are created.

To enable or disable the Authorization in OIF/IdP, you will need to execute the following OIF WLST commands:

  • 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 configureFedSSOAuthz() command:
    • To enable authorization:
      configureFedSSOAuthz("true")
    • To disable authorization:
      configureFedSSOAuthz("false")
  • Exit the WLST environment:
    exit()

Token Issuance Policy


Overview

As mentioned earlier, a Token Issuance Policy is made of two objects:

  • A list of resources, with each resource containing the name of the SP Partner
  • A list of constraints, each constraint being one of the following:
    • The true constraint which is used to indicate that OIF/IdP should issue tokens for all users for the SP partners listed in the policy
    • The Identity constraint made of
      • List of users: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to that list
      • Or list of groups: OIF/IdP will ensure that the user performing Federation SSO between OIF and the remote SP belongs to a group listed in the constraint
  • Rules using the constraints

During a Federation SSO operation, after user authentication, OIF/IdP will check if Authorization is enabled and if yes, it will collect the user’s identity and the groups to which it belongs, the SP Partner name and will invoke OAM Authorization Engine that will indicate whether or not the evaluation was successful:

  • If successful, it means that
    • The SP Partner name was listed as a resource in one in the Token Issuance Policy
    • Evaluation of the constraints for one of the Token Issuance Policies where the SP partner is listed
      • Either a true constraint was present
      • Or an Identity constraint was present
        • With the user’s identity
        • Or with a group to which the user belongs to

In the examples listed in this article, we will add all the Token Issuance Policies to the IAM Suite Application Domains in the OAM Administration Console.

Test Environment

I will showcase usage of the Authorization feature by using examples with:

  • Three users in the LDAP directory used by OIF/IdP (see below for the LDIF output)
    • alice
    • bob
    • charlie
  • Three groups in the LDAP directory
    • Engineers, to which bob and charlie belong
    • Managers, to which alice belongs
    • Employees, to which alice, bob and charlie belong
  • Four SP Partners: OnlineConference.com, HR, TravelSite and 401kSP
  • Three authorization policies
    • Authz #1: only users of group Employees minus bob can access 401kSP
    • Authz #2: only users of group Managers and user charlie can access HR
    • Authz #3: anybody can access TravelSite and OnlineConference.com

The LDIF output from the test LDAP directory for the three users is:

# alice, users, us.oracle.com
dn: cn=alice,ou=users,dc=us,dc=oracle,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenName: Alice
uid: alice
cn: alice
sn: Appleton
mail: alice@oracle.com

# bob, users, us.oracle.com
dn: cn=bob,ou=users,dc=us,dc=oracle,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenName: Bobby
uid: bob
cn: bob
sn: Smith
mail: bob@oracle.com

# charlie, users, us.oracle.com
dn: cn=charlie,ou=users,dc=us,dc=oracle,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenName: Charlie
uid: charlie
cn: charlie
sn: Crown
mail: charlie@oracle.com

The LDIF output from the test LDAP directory for the three groups is:

# Managers, groups, us.oracle.com
dn: cn=Managers,ou=groups,dc=us,dc=oracle,dc=com
uniqueMember: cn=alice,ou=users,dc=us,dc=oracle,dc=com
cn: Managers
objectClass: groupOfUniqueNames
objectClass: top

# Employees, groups, us.oracle.com
dn: cn=Employees,ou=groups,dc=us,dc=oracle,dc=com
uniqueMember: cn=charlie,ou=users,dc=us,dc=oracle,dc=com
uniqueMember: cn=alice,ou=users,dc=us,dc=oracle,dc=com
uniqueMember: cn=bob,ou=users,dc=us,dc=oracle,dc=com
cn: Employees
objectClass: groupOfUniqueNames
objectClass: top

# Engineers, groups, us.oracle.com
dn: cn=Engineers,ou=groups,dc=us,dc=oracle,dc=com
uniqueMember: cn=bob,ou=users,dc=us,dc=oracle,dc=com
uniqueMember: cn=charlie,ou=users,dc=us,dc=oracle,dc=com
cn: Engineers
objectClass: groupOfUniqueNames
objectClass: top

Examples


Use Case #1

In this use case:

  • 401kSP is the name of the SAML 2.0 SP partner
  • OIF/IdP must allow users belonging to the Employees group to do Federation SSO with that SP Partner
  • OIF/IdP must disallow bob to do Federation SSO with that SP Partner

To configure OIF/IdP for this use case, 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
  • Click in IAM Suite in the list of results
  • Click on the Token Issuance Policies tab
  • Click “Create Token Issuance Policy”
  • Enter a name (for example EmployeesPolicy)

Execute the following steps:

  • Click on Conditions tab
  • Click Add to add a constraint for the employees group
  • Enter the details of the constraints:
    • Name: for example EmployeesGroup
    • Type: Token Requestor Identity

Execute the following steps:

  • Click Add Selected
  • Select the newly created constraint to configure it
    • In the conditions details, click Add and select Add Identities
    • Select the Identity Store where user exist
    • Click search
    • Select the Employees Group

Execute the following steps:

  • Click Add Selected


Execute the following steps:

  • Click Add to add another constraint for user bob
  • Enter the details of the constraints:
    • Name: for example BobUser
    • Type: Token Requestor Identity

Execute the following steps:

  • Click Add Selected
  • Select the newly created constraint to configure it
    • In the conditions details, click Add and select Add Identities
    • Select the Identity Store where user exist
    • Click search
    • Select the user bob

Execute the following steps:

  • Click Add Selected

Execute the following steps:

  • Click on the Rules tab
  • In the Allow Rule section, select the EmployeesGroup condition and add it to the Selected Conditions, since we want to allow users belonging to the Employees group to do Federation SSO with the partners listed in this policy
  • In the Deny Rule section, select the BobUser condition and add it to the Selected Conditions, since we want to disallow bob to do Federation SSO with the partners listed in this policy
  • Click Apply

Execute the following steps to create a new resource and add it to the EmployeesPolicy Token Issuance Policy:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Click Search
  • Click in IAM Suite in the list of results
  • Click on the Resources tab
  • Click on New Resource and create a new resource for the Token Issuance Policy:
    • Type: TokenServiceRP
    • Resource URL, name of the SP Partner as it was created in the Federation Admin section: 401kSP
    • Operations: all
    • Token Issuance Policy: EmployeesPolicy
    • Apply


Use Case #2

In this use case:

  • HR is the name of the SAML 2.0 SP partner
  • OIF/IdP must allow users belonging to the Managers group to do Federation SSO with that SP Partner
  • OIF/IdP must allow charlie to do Federation SSO with that SP Partner

To configure OIF/IdP for this use case, 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
  • Click in IAM Suite in the list of results
  • Click on the Token Issuance Policies tab
  • Click “Create Token Issuance Policy”
  • Enter a name (for example HRPolicy)
  • Click on Conditions tab
  • Click Add to add a constraint for the employees group
  • Enter the details of the constraints:
    • Name: for example HRCondition
    • Type: Token Requestor Identity
  • Click Add Selected
  • Select the newly created constraint to configure it
    • In the conditions details, click Add and select Add Identities
    • Select the Identity Store where user exist
    • Click search
    • Select the Managers Group and the charlie user
  • Click Add Selected

Execute the following steps:

  • Click on the Rules tab
  • In the Allow Rule section, select the HRCondition condition and add it to the Selected Conditions, since we want to allow users belonging to the Managers group and user charlie to do Federation SSO with the partners listed in this policy
  • Click Apply

Execute the following steps to create a new resource and add it to the HRPolicy Token Issuance Policy:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Click Search
  • Click in IAM Suite in the list of results
  • Click on the Resources tab
  • Click on New Resource and create a new resource for the Token Issuance Policy:
    • Type: TokenServiceRP
    • Resource URL, name of the SP Partner as it was created in the Federation Admin section: HR
    • Operations: all
    • Token Issuance Policy: HRPolicy
    • Apply

Use Case #3

In this use case:

  • TravelSite is the name of the first SAML 2.0 SP partner
  • OnlineConference.com is the name of the second SAML 2.0 SP partner
  • OIF/IdP must allow all users to do Federation SSO with those SP Partners

To configure OIF/IdP for this use case, 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
  • Click in IAM Suite in the list of results
  • Click on the Token Issuance Policies tab
  • Click “Create Token Issuance Policy”
  • Enter a name (for example AllUsersPolicy)
  • Click on Conditions tab
  • Click Add to add a constraint for the employees group
  • Enter the details of the constraints:
    • Name: for example TrueCondition
    • Type: Token Requestor Identity

Execute the following steps:

  • Click Add Selected

Execute the following steps:

  • Click on the Rules tab
  • In the Allow Rule section, select the TrueCondition condition and add it to the Selected Conditions, since we want to allow all users to do Federation SSO with the partners listed in this policy
  • Click Apply

Execute the following steps to create a new resource and add it to the HRPolicy Token Issuance Policy for the TravelSite and OnlineConference.com partners:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Click Search
  • Click in IAM Suite in the list of results
  • Click on the Resources tab
  • Click on New Resource and create a new resource for the Token Issuance Policy for TravelSite:
    • Type: TokenServiceRP
    • Resource URL, name of the SP Partner as it was created in the Federation Admin section: TravelSite
    • Operations: all
    • Token Issuance Policy: AllUsersPolicy
    • Apply
  • Click on New Resource and create a new resource for the Token Issuance Policy for OnlineConference.com:
    • Type: TokenServiceRP
    • Resource URL, name of the SP Partner as it was created in the Federation Admin section: OnlineConference.com
    • Operations: all
    • Token Issuance Policy: AllUsersPolicy
    • Apply

Summary

To view the Resources for the SP Partners created above, 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
  • Click in IAM Suite in the list of results
  • Click on the Resources tab
  • Select TokenServiceRP as the Resource Type
  • Click Search
    • The list of resources of type TokenServiceRP will be displayed
    • MissingRP and UnknownRP are related to OSTS Authorization Policies
    • HR, TravelSite, OnlineConference.com and 401kSP are displayed


In the next article, I will be discussing how to configure OIF/SP to map the attribute names from an incoming SSO Assertion to local names, and how to use them in OAM Authorization policies, or how to provide them to protected web applications via HTTP Headers or cookies.
Cheers,
Damien Carru

Comments:

Hey Damien, great post, I'm looking to upgrade our infrastructure from 11.1.2.0.0 to the new patch set 11.1.2.2.0... until then, I have OAM 11.1.2.0.0 and OIF 11.1.1.2.0, where OIF is acting as an IdP.

I have been having some rough times trying to figure out how to send the providerid (or alias) from OIF to OAM so that OAM can look at the value, and then do some condition based authorizations based on the value.

I submitted a community question that I have been trying to work through, it has more details:
https://community.oracle.com/thread/3567449

Basically... what can I do in OAM to see the providerid from OIF when OIF is acting as the IdP and doesn't have any session info or attributes? The custom actions shows OIF passes the oracle.security.fed.authn.providerid in the request attributes, but doesn't seem like there is any way to access that in OAM unless I just don't know the proper namespace syntax.

Thanks,

Posted by William Fry on June 05, 2014 at 03:02 PM EDT #

Hi,

Unfortunately, being able for OAM to enforce authorization rules for Federation SSO based on the SP's ProviderID is only possible in OIF 11.1.2.2.0, where OIF and OAM are tightly integrated: this integration allowed for features that were not technically feasible in previous versions of OAM & OIF, such as multi authentication scheme support in OIF/IdP, providing SAML attributes as HTTP headers to web apps protected by WebGate, authorization in OIF/IdP based on the SP...

Here are why the below approaches cannot be used for Authorization:
- OAM/WebGate cannot be leveraged, because the ProviderID will not be available in the URL as a standalone query parameter: not in the /fed/user/authnoam11g URL and not in the /fed/idp/samlv20 URL (it is available for IdP initiated SSO flows /fed/idp/initiatesso, but not in SP initiated SSO flows where the ProviderID is encoded in the AuthnRequest at /fed/idp/samlv20)
- a pre/post custom authentication module will not work, because those modules are only invoked when OIF/IdP needs to authenticate the user. If the user is already authenticated, the authentication module won't be invoked
- setting the session timeout to 0 to force the authentication to occur every time is an very insecure approach as it will result in OIF removing the expired sessions: at logout, when the user's browser executes the SAML global logout, OIF/IdP would not be able to notify the partners of the user signing off, since the sessions would have been expired and removed already from the OIF backend.

Note: in OIF 11gR1, oracle.security.fed.authn.providerid is only available as an attribute on the HttpServlerRequest in the custom engines, retrievable via the getAttribute() method. It is not available to OAM.

Regards,
Damien

Posted by Damien on June 06, 2014 at 01:18 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
« July 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