Using Fed Attributes: OAM Authorization and HTTP Headers

This article describes 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 OAM/SP successfully processes a SAML / OpenID SSO Response message, the server saves some of the information from the response in the OAM session, as attributes that can be used in OAM authorization policies

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

Overview

A typical OAM environment is made of the following:

When an authenticated user requests access to a protected resource:

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

An administrator could use the Federation data received in the SAML/OpenID SSO message in an authorization rule, by using an attribute condition that evaluates 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

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

Use the same SAML 2.0 Federation setup that was configured for the previously, where:

Two users will be used:

Alice:

Bob:

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 OAM/SP processed the attributes according to the rules where:

Description of the illustration Test_Federation_SSO.jpg

Protected Web Application

In this example, use the following components:

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

Description of the illustration Protected_web_Application.jpg

Authorization Conditions

The following example shows how to construct an Authorization Policy using a Federation attributes stored in the OAM session for a resource with the following constraints:

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

  1. Go to the OAM Administration Console: http(s)://oam-admin-host:oam-adminport/oamconsole

  2. Navigate to Access Manager , Application Domains

  3. Search and click on the Application Domain for the resource

  4. Click on the Authorization Policies

  5. Open the Authorization Policy protecting the resource (Protected Resource Policy in this example)

  6. Click on the Conditions tab

  7. Click Add to define a new condition:

    1. Name: TitleCondition

    2. Type: Attribute

  8. Click Add Selected

    9. Description of the illustration Add_Condition.jpg

  9. Select the newly created condition

  10. In the Condition Details window, click Add:

    • Namespace: Session

    • Attribute Name: Other

    • Enter the attribute name: fed.title

    • Operator: Equals

    • Attribute Value: manager

  11. Click OK

    12. Description of the illustration Add_Attr_Condition.jpg

  12. Click on the Rules tab

  13. Remove the TRUE condition if present in the Allow Rule , Selected Conditions

  14. Add the TitleCondition to the Allow Rule , Selected Conditions

  15. Click Apply

Description of the illustration Authorization_Policy.jpg

To test, in a new browser access the protected resource. You will be redirected to the IdP.

If you authenticate at the IdP with alice, the browser shows the following at the end of the now, 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):

Description of the illustration Document_root.jpg

If you authenticate at the IdP with bob, the browser shows the following at the end of the now, 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):

Description of the illustration OAM_Operation_error.jpg

Injecting Fed Attributes

The following example shows how to inject SAML / OpenID attributes collected from the SSO response as HTTP Headers for the protected Web with the following constraints:

The configuration is done via the use of Authorization Response objects in an Authorization Policy definition

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

  1. Go to the OAM Administration Console: http(s)://oam-admin-host:oam-adminport/oamconsole

  2. Navigate to Access Manager , Application Domains

  3. Search and click on the Application Domain for the resource

  4. Click on the Authorization Policies

  5. Open the Authorization Policy protecting the resource (Protected Resource Policy in this example)

  6. Click on the Responses tab

  7. Click Add to create the entry for the email address:

    • Type: Header

    • Name: emailaddress

    • Value: $session.attr.fed.attr.email

  8. Click Add

    Description of the illustration Add_Response.jpg

  9. Click Add to create the entry for the first name:

    • Type: Header

    • Name: firstname

    • Value: $session.attr.fed.attr.firstname

  10. Click Add

  11. Click Add to create the entry for the last name:

    • Type: Header

    • Name: lastname

    • Value: $session.attr.fed.attr.lastname

  12. Click Add

  13. Click Apply

Description of the illustration ACS_Authorization_Policy.jpg

To test, in a new browser access the protected resource. You will be redirected to the IdP where authentication occurs.

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

Description of the illustration Authorization_Response.jpg

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.