Using Fed Attributes: OAM Authorization and HTTP Headers

In this article, I will discuss how attributes received in SAML/OpenID SSO messages can be used in OAM Authorization Policies and how they can be provided to protected web applications.

At runtime, when OIF/SP successfully processes a SAML / OpenID SSO Response message, the server will save some of the information from the response in the OAM session, as attributes that can be used in OAM authorization policies

  • In conditions for authorization rules
  • In responses to provide the SAML/OpenID attributes to protected web applications

The SAML / OpenID SSO Response information is saved in the OAM session as attributes referenced by the following identifiers:

  • The IdP partner name, referenced by $session.attr.fed.partner
  • The NameID value from the SSO response, referenced by $session.attr.fed.nameidvalue
  • The NameID format from the SSO response, for SAML protocols, referenced by $session.attr.fed.nameidformat
  • The attributes contained either in the SAML Assertion’s AttributeStatement or in the OpenID SSO Response, referenced by $session.attr.fed.attr.ATTR_NAME, with ATTR_NAME being
    • Either the local session attribute name, if an IdP Attribute Profile mapping was applied (see previous article)
    • Or the attribute name from the SSO response, if no IdP Attribute Profile mapping was applied for this attribute

Enjoy the reading!

Overview


A typical OAM environment is made of the following:

  • LDAP directory
  • OAM admin server, with the OAM admin console
  • OAM runtime server
  • Web applications
  • WebGate agents protecting web application on HTTP servers (OHS, IIS…)

When an authenticated user requests access to a protected resource:

  • WebGate intercepts the call and ensures that
    • The user is authenticated
    • The user is authorized to access the resource by evaluating authorization policies for this resource
  • WebGate will inject data, as cookies or HTTP headers, into the HTTP request that will be forwarded to the protected resource

The OAM Authorization Policies used to evaluate whether a user can access a resource or not can be based on various conditions:

  • Identity: condition based on the user’s identity or groups to which the user belongs
  • IP Address: condition based on the user’s IP address
  • Temporal: condition based on time
  • Attributes: condition based on attributes (LDAP, HTTP request or session attributes).

An administrator could use the Federation data received in the SAML/OpenID SSO message in an authorization rule, by using an attribute condition that would evaluate the Federation attributes.

The OAM Authorization Responses which are used to inject data into the HTTP request to make it available to protected web applications are based on

  • User LDAP attributes
  • HTTP request data
  • Static strings
  • OAM session attributes

Similarly to the OAM Authorization Policies, an administrator can inject federation data into the HTTP request via the use of OAM session attributes referencing the federation entries ($session.attr.fed.partner, $session.attr.fed.attr.ATTR_NAME…)

Federation SSO Setup


I will use the same SAML 2.0 Federation setup that was configured for the previous article, where:

  • OIF acts as a Service Provider
  • The IdP (AcmeIdP) will send a SAML Assertion with
    • NameID set to userID
    • Attributes sent:
      • email set to user’s email address
      • fname set to user’s first name
      • surname set to user’s last name
      • title set to user’s last job title
  • OIF/SP configured with an IdP Attribute Profile to
    • Map fname to firstname
    • Map surname to lastname
    • Leave email as is

Two users will be used:

  • Alice:
    • userID: alice
    • email: alice@oracle.com
    • first name: Alice
    • last name: Appleton
    • title: manager
  • Bob:
    • userID: bob
    • email: bob@oracle.com
    • first name: Bobby
    • last name: Smith
    • title: engineer

The XML SAML Response with the Assertion sent back by the IdP is:

<samlp:Response ..>
    <saml:Issuer ...>http://acme.com/idp</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>http://acme.com/idp</saml:Issuer>
        <dsig:Signature ...>
        ...
        </dsig:Signature>
        <saml:Subject>
            <saml:NameID ...>alice</saml:NameID>
            ...
        </saml:Subject>
        <saml:Conditions ...>
         ...
        </saml:Conditions>
        <saml:AuthnStatement ...>
        ...
        </saml:AuthnStatement>
        <saml:AttributeStatement ...>
            <saml:Attribute Name="email" ...>
                <saml:AttributeValue ...>alice@oracle.com</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="title" ...>
                <saml:AttributeValue ...>manager</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="surname" ...>
                <saml:AttributeValue ...>Appleton</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="fname" ...>
                <saml:AttributeValue ...>Alice</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The Test SP page shows different results, since OIF/SP processed the attributes according to the rules where:

  • email was not changed
  • title was not changed
  • fname was mapped to firstname
  • surname was mapped to lastname

Protected Web Application


In this example, I am using the following components:

  • OHS is installed
  • A WebGate agent has been configured for this OHS instance
  • An OAM Application Domain has been created for this WebGate, which protects all the resources on the OHS server
    • Authentication Policy:
      • Name: “Protected Resource Policy”
      • Authentication Scheme: FederationScheme
    • Authorization Policy:
      • Name: “Protected Resource Policy”
    • Resources
      • /** and /…/*
      • Linked to “Protected Resource Policy” Authentication Policy and “Protected Resource Policy” Authorization Policy
  • The /cgi-bin/printenv resource on OHS prints out data when processing the the HTTP Request sent by the browser
    • HTTP Headers
    • Request data (path, query string...)
    • Server data (IP address, port…)

An example of a browser accessing the resource without being protected by OAM/WebGate would result in the following display (in the test, the web application will be protected as listed above):

Authorization Conditions


I will show as an example how to construct an Authorization Policy using a Federation attributes stored in the OAM session for a resource with the following constraints:

  • Users will be authenticated via Federation SSO (so the resource is protected via a FederationScheme Authentication Policy)
  • The IdPs provide the job title of the user, and it will be known locally as title (if the IdP sends the job title via a name different than title, then an IdP Attribute Profile will need to be used to map it to the local title name)
  • Only users with the manager title should have access to the resource

To create such an authorization policy, execute the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Search and click on the Application Domain for the resource
  • Click on the Authorization Policies
  • Open the Authorization Policy protecting the resource (“Protected Resource Policy” in this example)
  • Click on the Conditions tab
  • Click Add to define a new condition:
    • Name: TitleCondition
    • Type: Attribute
    • Click Add Selected

Execute the following steps:

  • Select the newly created condition
  • In the Condition Details window, click Add:
    • Namespace: Session
    • Attribute Name: Other
    • Enter the attribute name: fed.title
    • Operator: Equals
    • Attribute Value: manager
    • Click OK

Execute the following steps:

  • Click on the Rules tab
  • Remove the TRUE condition if present in the Allow Rule -> Selected Conditions
  • Add the TitleCondition to the Allow Rule -> Selected Conditions
  • Apply

To test, in a fresh browser access the protected resource: you will be redirected to the IdP.

If you authenticate at the IdP with alice, the browser will show the following at the end of the flow, showing the Remote User HTTP header set to alice (since the IdP provided the title attribute set to manager and OAM only allows access to users with the OAM session attribute fed.title set to manager):

If you authenticate at the IdP with bob, the browser will show the following at the end of the flow, showing an error (since the IdP provided the title attribute set to engineer and OAM only allows access to users with the OAM session attribute fed.title set to manager):


Injecting Fed Attributes


I will show as an example how to inject SAML / OpenID attributes collected from the SSO response as HTTP Headers for the protected Web with the following constraints:

  • Users will be authenticated via Federation SSO (so the resource is protected via a FederationScheme Authentication Policy)
  • The IdPs provide the job title of the user, and it will be known locally as title (if the IdP sends the job title via a name different than title, then an IdP Attribute Profile will need to be used to map it to the local title name)
  • OAM/WebGate will be configured to inject:
    • Email address as emailaddress
    • First name as firstname
    • Last name as lastname
  • The configuration will be done via the use of Authorization Response objects in an Authorization Policy definition

To configure such an authorization policy, execute the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Access Manager -> Application Domains
  • Search and click on the Application Domain for the resource
  • Click on the Authorization Policies
  • Open the Authorization Policy protecting the resource (“Protected Resource Policy” in this example)
  • Click on the Responses tab
  • Click Add to create the entry for the email address:
    • Type: Header
    • Name: emailaddress
    • Value: $session.attr.fed.attr.email
    • Add

Execute the following steps:

  • Click Add to create the entry for the first name:
    • Type: Header
    • Name: firstname
    • Value: $session.attr.fed.attr.firstname
    • Add
  • Click Add to create the entry for the last name:
    • Type: Header
    • Name: lastname
    • Value: $session.attr.fed.attr.lastname
    • Add
  • Apply

To test, in a fresh browser access the protected resource: you will be redirected to the IdP where authentication will occur.

OAM/WebGate will then inject the Authorization Response items based on the OAM Session attributes (received from the IdP) and the protected web application will display those (my test page will display an HTTP header as HTTP_NAME, with NAME being the name of the HTTP Header).


In my next article, I will discuss on how to add user provisioning to OIF/SP which allows the server to create a user record on the fly during Federation SSO, if the user does not have an account yet.
Cheers,
Damien Carru

Comments:

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
« February 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
       
       
Today