41 Using Identity Context

Identity Context allows organizations to meet growing security threats by leveraging the context-aware policy management and authorization capabilities built into the Oracle Access Management platform. Identity Context secures access to resources using traditional security controls (such as roles and groups) as well as dynamic data established during authentication and authorization (such as authentication strength, risk levels, device trust and the like). The following sections contain additional information on Identity Context and how to use it.

41.1 Introducing Identity Context

Over the last decade, changes have been made to enterprise application infrastructures in order to web-enable the business applications that these infrastructures support. The changes allow for access by a greater number of users using different types of devices. To compensate for the additional risk associated with the greater number of users, the underlying security models used for access management have evolved from a silo-based implementation to a more dynamic one in which identity and risk data is shared across components of the entire application delivery process. This dynamic implementation relies on systems that offer Web single sign-on (SSO), fine-grained authorization, Web Services Security, Identity Federation and the like to aggregate security controls within a particular run-time deployment environment (web server or application server container) and provide policy-based security controls to manage access to application resources. Additionally, the identity and risk data provides a context for the user who is requesting access.

Initially, application security controls focused on unifying silos within a specific enterprise application deployment paradigm (for example, all web server applications, all web services applications, or all application server applications) but a growing presence of external and internal security threats now requires the unification of disparate security models in order to properly manage the greater amount of risk.

This requirement is further magnified by the advent of the cloud and mobile computing paradigm in which applications are no longer made up of components running neatly in the protected confines of a secure enterprise.

The ability of applications to leverage cloud services comes at the cost of having to account for the greater amount of risk stemming from those services being silos in their own way. With the number of threats to cloud deployments and mobile delivery channels growing steadily, it is required for the end-to-end application delivery process to implement the necessary policy controls for dealing with the greater range of threats. These policy controls require access to information about the requesting user on the basis of which security decisions must be made. Thus, a security policy management infrastructure must be context-aware to allow for an Administrator to create policy that controls the level of security imposed on a user who is requesting access to a protected application environment.

Previously, Identity Context was defined by the presence of an identity record in one or more identity stores (such as an LDAP directory or a SQL database). The identity record includes profile attributes, groups of which the user is a member, and enterprise roles. However, the constantly expanding reach of web, cloud, and mobile application delivery channels requires authorization policy controls that are aware of more dynamic information regarding the identity. This information is associated with the identity attempting to access the protected resource and may include some or all of the following:

  • Presence (location, historical patterns)

  • Authentication strength (weak, strong)

  • Level of Assurance (NIST levels, X509 certificates)

  • Risk Assessment (pattern analysis)

  • Federation (partner attributes)

  • Device characteristics (fingerprint, device health, device protection, trusted data)

  • Assertions from trusted partners (SAML tokens, etc.)

  • Single Sign On sessions (session time outs)

The following examples illustrate how Identity Context data might be used by an application. The application might:

  • Disable a particular business function if the user is not authenticated using a strong credential such as smart card.

  • Secure access to a transaction based on the identity data supplied by a business partner (via Identity Federation) with whom the organization does business.

  • Request additional authentication credentials if it detects that access is originating from a location known for fraudulent activities.

  • Limit the scope of administrative authority if the Administrator's industry certification (as maintained by a third party) has expired.

  • Disable certain business functions if it detects that access is originating from an unknown device.

By incorporating the concept of Identity Context into access management, control can now be determined using dynamic data that is not necessarily contained in an identity profile (referred to as Identity Context attributes). In short, Identity Context is considered the environment and circumstances surrounding a user's request to access a particular protected resource. It can be a sphere of activity, a geographical region, a communication platform, an application, or a logical or physical domain.

41.2 Understanding Identity Context

With this release, Access Manager enables context-aware access management by incorporating Identity Context as a built-in service of the Oracle Access Management platform. Figure 41-1 illustrates the flow of the Identity Context process, implemented by multiple system components. Each application delivery component has its own security policy infrastructure responsible for protecting its individual slice of the application. This specific use case involves the end user device, a Web Server running static GUI pages, an Application Server running the Portal Server rendering dynamic content, a Service Bus Server exposing the Web service endpoint, a database server containing transactional data, and an LDAP server containing identity profile data.

Figure 41-1 End to End Identity Context Process

Description of Figure 41-1 follows
Description of "Figure 41-1 End to End Identity Context Process"

Each component of the process has its own security infrastructure where the authorization policies governing access to protected resources are defined administratively and enforced at runtime. Additionally, some or all of the components may have externalized policy management to an external authorization server such as Oracle Entitlements Server - which is the case if the applications were built leveraging Oracle Platform Security Services. Figure 41-2 illustrates the functional architecture of Identity Context based on the Oracle applications of which it is comprised.

Figure 41-2 End To End Identity Context Process Components

Description of Figure 41-2 follows
Description of "Figure 41-2 End To End Identity Context Process Components"

As seen in the illustrations, context-aware security policy management is achieved by leveraging the Oracle Access Management platform. This platform contains native support for working with and enforcing Identity Context attributes (including risk score, trusted device data, authentication data, and the like) without changing end-user applications.

41.3 Working With the Identity Context Service

The Oracle Access Management platform enables Identity Context data to be collected, propagated across the involved components (as defined in Figure 41-2), and made available for granting or denying authorization to access protected resources. The Identity Context Service allows access to the Identity Context Runtime through the Identity Context API. The Identity Context Dictionary schema specifies the Identity Context attributes. The following sections contain more information on these components.

41.3.1 Using the Identity Context Dictionary

At the core of the Identity Context architecture is the Identity Context Dictionary. The dictionary defines the Identity Context schema by specifying the identity context attributes as defined by the Oracle Access Management platform. The Schema describes each attribute with a unique name that equals namespace : attribute. Table 41-1 documents the Schema attributes.

Note:

Virtual attributes (as documented in Table 41-1) represent an abstract class of identity information from which specific attributes are created. When publishing virtual attributes, the Identity Context API expects the attribute value to contain attr-name=attr-value. The actual attribute will be created using the name namespace : attribute : attr-name and a value of attr-value. This approach allows the publication of attributes whose value comes from a source not directly managed by the Oracle Access Management components.

Table 41-1 Identity Context Schema Attributes

Namespace Attribute Type Virtual Primary Publisher Description

oracle:idm:claims:nameid

value

string

no

OAM

Indicates a unique user identifier. Access Manager currently publishes User DN

oracle:idm:claims:nameid

format

string

no

OAM

Indicates the type of user identifier. Access Manager currently publishes "urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectName"

oracle:idm:claims:nameid

qualifier

string

no

OAM

Indicates a logical Identity Domain to whom the user belongs. Access Manager currently publishes a logical name of the identity store, such as UserIdentityStore1.

oracle:idm:claims:nameid

spprovidedid

string

no

OAM

Indicates unique identifier that can be used by any SP to locate the user in SP's own identity store(s). Access Manager currently publishes the value of the unique id attribute as configured in a registered identity store.

oracle:idm:claims:client

firewallenabled

boolean

no

OESSO

Indicates client device has firewall enabled.

oracle:idm:claims:client

antivirusenabled

boolean

no

OESSO

Indicates client device has antivirus enabled.

oracle:idm:claims:client

fingerprint

string

no

OESSO, Oracle Access Management Mobile and Social (OMS)

Indicates fingerprint of the client device.

oracle:idm:claims:client

ostype

string

no

OMS

Indicates client device's Operating System type.

oracle:idm:claims:client

osversion

string

no

OMS

Indicates client device's operating system version.

oracle:idm:claims:client

jailbroken

boolean

no

OMS

Indicates if client device is Jailbroken (iOS) or Rooted (Android).

oracle:idm:claims:client

macaddress

string

no

OMS

Indicates client device's Ethernet (MAC) Address.

oracle:idm:claims:client

ipaddress

string

no

OMS

Indicates client device's Client IP Address.

oracle:idm:claims:client

vpnenabled

boolean

no

OMS

Indicates if client's device has VPN enabled.

oracle:idm:claims:client

geolocation

string

no

OMS

Indicates client device location's geographical coordinates in the form of "latitude,longitude.

oracle:idm:claims:risk

newdevice

boolean

no

OAAM

Indicates if the client device has been seen before. True when logging in from a device never seen before; otherwise, false.

oracle:idm:claims:risk

level

integer

no

OAAM

Indicates risk level. Level increases after unsuccessful logins.

oracle:idm:claims:risk

safeforuser

boolean

no

OAAM

Indicates if the user answered a secondary challenge question. True after the user successfully answers it; otherwise false.

oracle:idm:claims:risk

fingerprint

string

no

OAAM

Indicates device fingerprint as measured by OAAM. Different devices will leave different fingerprints; can be switched between device (obtained via Flash) fingerprint and browser (http-only) fingerprint

oracle:idm:claims:session

authnlevel

integer

no

OAM

Indicates authentication level for Access Manager

oracle:idm:claims:session

usercount

integer

no

OAM

Indicates number of sessions held by the users

oracle:idm:claims:session

appdomain

string

no

OAM

Indicates name of the Access Manager Application Domain containing policies

oracle:idm:claims:session

apppolicy

string

no

OAM

Indicates name of the Access Manager policy that allowed access

oracle:idm:claims:session

appagent

string

no

OAM

Indicates the name of the agent from which the request came to Access Manager

oracle:idm:claims:session

appclientip

string

no

OAM

Indicates the IP address of the client sending the request to Access Manager

oracle:idm:claims:session

sessionid

string

no

OAM

Indicates the Access Manager session ID

oracle:idm:claims:session

attributes

string

yes

OAM

Indicates session attributes as retrieved from the session store. For example, in Access Manager, select "oracle:idm:claims:session:attributes" as the claim name and then specify the session attribute using the following notation: "attr-name=$session.attr.name where name is the name of the attribute stored in the session. The claim will be created with the name of "oracle:idm:claims:session:attributes:attr-name" and value equal to session's name attribute.

oracle:idm:claims:fed

partner

string

no

OAM--or IF?

Indicates partner ID as determined by Identity Federation

oracle:idm:claims:fed

nameidvalue

string

no

OAM--or IF?

Indicates user ID from a federation partner as determined by Identity Federation

oracle:idm:claims:fed

nameidformat

string

no

OAM--or IF?

Indicates format of the user ID from a federation partner as determined by Identity Federation

oracle:idm:claims:fed

attributes

string

yes

OAM

Indicates federation attribute as supplied by the partner and determined by Identity Federation. For example, in Access Manager, select "oracle:idm:claims:fed:attributes" as the claim name and then specify the federation attribute using the following notation: "attr-name=$session.attr.fed.attr.name, where name is the name of the SAML attribute in the partner's SAML assertion. The claim will be created with the name of "oracle:idm:claims:fed:attributes:attr-name" and value equal to the partner's assertion provided in the SAML's name attribute.

oracle:idm:claims:ids

attributes

string

yes

OAM

For example, in Access Manager, select "oracle:idm:claims:ids:attributes" as the claim name, and then specify the ID Store attribute using the following notation: "attr-name=$user.attr.name where name is the name of the attribute on the user profile. The claim will be created with the name of "oracle:idm:claims:ids:attributes:attr-name" and value equal to user profile's name attribute.

oracle:idm:claims:tenant

tenantid

string

no

OAM

Currently reserved for future use. (Indicates tenant id.)

oracle:idm:claims:tenant

attributes

string

yes

OAM

Currently reserved for future use. (Indicates tenant attributes as supplied by the Publisher. The claim value is meant to contain "attr-name=attr-value". The claim will be created with the name of "oracle.idm:claims:tenant:attr-name" and value of attr-value.)

41.3.2 Understanding Identity Context Runtime

Identity Context Runtime refers to a collection of Identity Context attributes (as defined in the Identity Context Dictionary) that is asserted by various trusted application components and/or security frameworks known to be authoritative for the attributes; this is the Oracle Access Management platform. Runtime context represents current surroundings, circumstances, environment, background, or settings which determine, specify, or clarify the meaning of an event for an identity in the runtime application environment.

The Oracle Access Management platform leverages a common infrastructure component called the Context Management Engine (CME). CME ensures that an Identity Context is generated for every transaction that is processed through the Oracle Access Management platform. The context data gathered by CME applies to transactions a user performs over the web channel or web service channel and using many of the software products available in the Oracle Access Management platform. Some transactions that are initiated on the back end may also require access to Identity Context, and may require Identity Context to be persisted for some duration of time.

In a typical Oracle middleware deployment the Identity Context Runtime will be utilized primarily by the Oracle Access Management platform to perform policy-based decisions on behalf of protected applications. However, it is also possible for any applications running in the container to directly integrate with, and consume, the Identity Context Runtime by leveraging the Identity Context API. The amount of available Identity Context data will vary depending on what products have been deployed. There will be a default set of Identity Attributes that will be available out-of the box, which are mainly configured in the Access Manager by leveraging the Identity Assertion. Table 41-1, "Identity Context Schema Attributes" documents these default attributes. The following list provides details on the end-to-end flow of the Identity Context Runtime. Figure 41-3 below the list illustrates the flow.

Process overview: End-to-end flow of the Identity Context Runtime

  1. User accesses a protected application from a device.

  2. Access Manager asserts the identity, collects Identity Attributes from the participating Access Management publishing components and creates an Identity Context.

  3. Access Manager generates an Identity Assertion (a SAML Session token) and incorporates the Identity Context attributes. The Access Manager Identity Asserter processes the Identity Assertion and publishes the Identity Context to the WebLogic Server container using the OPSS Attribute Service.

  4. The protected application calls the OES PEP API to make an authorization decision. OES automatically propagates the Identity Context to the local OES PDP.

  5. OES finds the appropriate Authorization Policy and evaluates it's Conditions (based on the Identity Context attributes). Evaluation can be done using a built-in Identity Context function or a custom function.

  6. The protected application makes a JRF web service call in which the Oracle Web Service Manager (OWSM) client uses the SAML token to propagate Identity Context into the Web Service application environment.

  7. OWSM (on the web service side) processes the SAML assertion with the Identity Context and publishes the Identity Context to the WebLogic Server container by using the OPSS Attribute Service.

  8. Web Service application calls OES PEP API to make an authorization decision.

  9. OES automatically propagates Identity Context to the remote OES PDP where conditions based on Identity Context attributes are evaluated using a built-in Identity Context function or a custom function.

Figure 41-3 Identity Context Process Flow

Surrounding text describes Figure 41-3 .

Once CME propagates Identity Context into the application tier and underlying Application Server container, the Identity Context is then made available to the container and applications running in it. Table 41-2 documents which Access Management platform products do what when working with Identity Context.

Table 41-2 Mapping Identity Context Operations

Role and Context Operation Description Components

Publisher - publishes Identity Context

Trusted security framework protecting an application component obtains from another trusted security framework, or derives from the information available to it, suitable facts about the identity and/or identity's access request.

The information collected by the authoritative component is based on the environmental context available to component's runtime framework. For example, Access Manager determines the user's level of authentication strength, OAAM computes the risk score associated with a specific online session, and OESSO determines whether or not the client device has a firewall enabled.

  • OAM – Session, Federation, and identity store attributes

  • OAAM – Risk attributes

  • OESSO – Device attributes

  • OMS Mobile SDK - Device attributes

Propagator - propagates Identity Context

Trusted security framework propagates Identity Context attributes for use by another application security framework or directly by the application. For example, OAAM propagates user's risk score into the Access Manager session for the user, Access Manager propagates Identity Assertion (SAML token) for with the authenticated user's unique id and authentication level, and OWSM client propagates the current Identity Context over to the web service where OWSM agent will rebuild Identity Context in the web service application.

  • OAM is between Web tier and container tier

  • OWSM is between web service client tier and web service tier

  • OPSS is between Access Manager Identity Asserter or OWSM agent and WebLogic Server container

  • OMS is between the OMS Mobile SDK and Access Manager

Evaluators - evaluate Identity Context

Trusted security framework or end-user application using Identity Context attributes to perform policy decisions or personalize application business logic. For example, when OAAM is present and configured to compute the risk score, the application's authorization policy in OES allows access only when the risk score is under a certain threshold. Also, when Identity Federation in Access Manager is configured, the application uses a partner-supplied assertion (available in the Identity Context) to authorize access to a transaction using OES.

  • OAM – Web Perimeter Policy

  • OWSM – Web Service policy

  • OES – App-specific or WLS-specific policy for all PEP API calls made from the container where Identity Context exists. This includes all ADF apps, IAM apps, custom apps, etc.

41.4 Using the Identity Context API

The Identity Context API is a set of Java classes designed to work with the Identity Context Dictionary and Identity Context Runtime. The API is delivered as IdentityContext.jar, a part of Oracle Java Required Files (JRF). Example 41-1 illustrates an application working with Identity Context Dictionary.

Example 41-1 Working with Identity Context Dictionary

// Display Identity Context Dictionary
try {
  ClaimDictionary idCtxDict = new ClaimDictionary();
  System.out.println
    ("IDC Dictionary :" + idCtxDict.getClaimCount() + "attributes");
  Iterator<String> iterNamespace = idCtxDict.getAllNamespaces();
  while (iterNamespace != null && iterNamespace.hasNext()) {
    String namespace = iterNamespace.next();
    System.out.println("Namespace : " + namespace);
    Iterator<ClaimSchema> 
iterClaimSchema=idCtxDict.getClaimsForNamespace(namespace);
    while (iterClaimSchema != null && iterClaimSchema.hasNext()) {
      out.println(iterClaimSchema.next().getUniqueName());
    }
  }
} catch (Exception e) {
  System.out.println("Unable to acquire IDC Dictionary. " + toString());
}

Applications work with the Identity Context Runtime to obtain the runtime state of the Identity Context as it currently exists in the application infrastructure. In order to work with the Identity Context Runtime, the protected application must be deployed to either a WebLogic Server domain built on Oracle Fusion Middleware PS5 with the OPSS Opatch for PS5, or Oracle Fusion Middleware PS6 or later.

Additionally, working with the Identity Context Runtime is a privileged operation that requires applications running in the WebLogic Server (with the required Identity Context support) to have proper source code grants. The privileged application, running in the WebLogic Server container, can then access the Identity Context Runtime by requesting it from the OPSS Attribute Service. Example 41-2 demonstrates how to use WLST to grant the OPSS Attribute Service permission to access an application (in this case, ssofilter.jar).

Example 41-2 Using WLST To Grant Attribute Service Access To Application

# sh ../oracle_common/common/bin/wlst.sh
connect ('<username>', '<password>','t3://localhost:7001')
grantPermission(codeBaseURL="file:${common.components.home}/
   modules/oracle.ssofilter_11.1.1/ssofilter.jar", permClass="oracle.security.jps.service.attribute.AttributeAccessPermission",
   permTarget="*", permActions="get, set, remove") 
exit()

Example 41-3 illustrates an application working with Identity Context Runtime.

Example 41-3 Working with Identity Context Runtime

import java.security.AccessController;
import java.security.PrivilegedAction;
import oracle.security.jps.internal.api.runtime.AppSecurityContext;
import oracle.security.idm.IdentityContext;
 
…
 
// get runtime ID Context from OPSS
private static Object getIDContext() {
  Object idc = AccessController.doPrivileged(new PrivilegedAction<Object>() {
                    public Object run() {return AppSecurityContext.getSecurityContext().getAttribute
  (oracle.security.idm.IdentityContext.Constants.IDC_API_ID); }});
  return idc;
}
 
…
 
// Display runtime ID Context
try {
  Context idCtx = (Context)getIDContext();
  if (idCtx != null) {
    System.out.println("IDC Runtime :" + idCtx.getSize() + "attributes");
    Iterator<Claim> i = idCtx.getClaims();
    while (i != null && i.hasNext()) {
      Claim c = i.next();
      System.out.println(c.getName() + " : " + c.getValue());
    }
  } else {
    System.out.println("Identity Context Runtime is not available");
  }
} catch (Exception e) {
  System.out.println("Unable to acquire Identity Context Runtime. " + e.toString());
}
 
…
 
// Obtain few attributes from Identity Context Runtime
Attr authnLevel = ctx.getAttr (Constants.ATTR_SESSION_AUTHN_LEVEL);
Attr isFirewallEnabled = ctx.getAttr(Constants.ATTR_CLIENT_FIREWALL_ENABLED);
Attr isTrustedDevice = ctx.getAttr(Constants.ATTR_RISK_TRUSTED_DEVICE);
 
// Use user's authentication strength established at login by OAM
int authLevel = new Integer(authnLevel.getValue()).intValue();
if (authLevel < 20) {
    // do something
}

More information can be found in the Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services.

41.5 Configuring the Identity Context Service Components

Support for Identity Context is pre-integrated into each participating Oracle Access Management component listed in Table 41-2, "Mapping Identity Context Operations". Because of this, each component must be configured to accommodate business requirements.

The following sections provide a high level overview of the necessary Identity Context configurations. However, detailed information can be found in documentation accompanying individual products.

41.5.1 Configuring Oracle Fusion Middleware

The application to be protected must be deployed in a WebLogic Server domain built on Oracle Fusion Middleware 11.1.1 patch set 5 (PS5) with the Oracle Platform Security Services (OPSS) Opatch for PS5 or, Oracle Fusion Middleware PS6 or later. The WebLogic Server domain in which the application is running must be protected by the Access Manager Identity Asserter component that will validate the Identity Assertion received from Access Manager and start the process of creating the Identity Context Runtime. The Access Manager Identity Asserter must be configured to detect the token type, OAM_IDENTITY_ASSERTION. Also, the protected application working with the Identity Context Runtime directly must be granted source code grants to work with the OPSS Attribute Service (as in Example 41-2).

See Also:

Oracle Fusion Middleware Application Security Guide for more information on configuring Access Manager Identity Asserter, as well a source code grants.

41.5.2 Configuring Access Manager

As the main publisher and propagator of Identity Context, OAM serves as the central configuration point for collecting Identity Context data from its participating components. The following sections describe key elements of the architecture behind Identity Context management.

41.5.2.1 Configuring Identity Assertion

Oracle recommends that you define Asserted Attributes in Access Manager Authorization policies for proper enforcement of end-to-end security between the Web and application tiers.

In addition to ensuring trust between the WebGate protecting a Web resource and the Application Server container, Identity Assertion (a SAML Session token) is used to publish the Identity Context data as SAML attributes.

Identity Assertion must be enabled and populated with Asserted Attributes as required by the business logic expecting specific attributes in the Identity Context. It is configured within the OAM Policy Responses tab and can be defined for both Authentication and Authorization policies.

See Also:

Access Manager Identity Assertion and Asserted Attributes (Table 17-11).

41.5.2.2 Configuring Federation Attributes

Once a resource is protected by the Access Manager authentication scheme FederationScheme, Access Manager will act as the service provider and receive the SAML assertion as provided by the federation partner. After the federation single sign on (SSO) operation, the following attributes will be present in the authenticated identity's Access Manager session:

  • $session.attr.fed.partner (contains the partner name)

  • $session.attr.fed.nameidvalue (contains the SAML NameID Value)

  • $session.attr.fed.nameidformat (contains the SAML NameID Format)

  • one $session.attr.fed.attr.name entry per SAML Attribute (contained in the SAML Assertion received from the partner)

    These federation attributes can be used in configuring an Identity Assertion by selecting oracle:idm:claims:fed:attributes as the Asserted Attribute, and setting the value to "attr-name=$session.attr.fed.attr.name" where attr-name is the name given to the Identity Context attribute and name is the name of the SAML attribute in the partner's SAML assertion.

    For example, defining oracle:idm:claims:fed:attributes with the value of partner-role=$session.attr.fed.attr.role will result in the creation of the Identity Context attribute oracle:idm:claims:fed:attributes:partner-role having a value of "manager" (assuming $session.attr.fed.attr.role contains "manager" as specified in the partner's SAML assertion for the SAML attribute "role").

41.5.2.3 Configuring Session Attributes

Access Manager session attributes can be used in configuring Identity Assertion by selecting oracle:idm:claims:session:attributes as the Asserted Attribute and setting the value to "attr-name=$session.attr.name" where attr-name is the name given to Identity Context attribute and name is the name of the Access Manager session attribute.

For example, defining oracle:idm:claims:session:attributes with the value of authn-strength=$session.attr.authnlevel will result in the creation of the Identity Context attribute oracle:idm:claims:session:attributes:authn-strength having a value as defined by the authentication scheme used during the login process.

41.5.2.4 Configuring Identity Store Attributes

Identity Store attributes can be used to configure an Access Manager Identity Assertion by selecting oracle:idm:claims:ids:attributes as the Asserted Attribute and setting the value to "attr-name=$user.attr.name" where attr-name is the name given to the Identity Context attribute and name is the name of the Identity Store attribute.

For example, defining oracle:idm:claims:ids:attributes with the value of first-name=$user.attr.fname will result in the creation of the Identity Context attribute oracle:idm:claims:ids:attributes:first-name having a value from the user's fname attribute as maintained in the identity store.

41.5.3 Configuring Oracle Adaptive Access Manager

As part of the integration between Oracle Access Manager and Oracle Adaptive Access Manager (OAAM), OAAM publishes and propagates risk-based Identity Context attributes. In this case, OAAM attributes are passed to OAM at the end of user authentication flow (on the OAAM side) in a DAP Token. The DAP Token will carry attributes as defined by the oracle:idm:claims:risk namespace in Table 41-1, "Identity Context Schema Attributes". OAM then pushes these attributes into the $session.risk.attr namespace. The following sections contain information regarding configuration of OAAM and OAM.

41.5.3.1 Setting Up Oracle Adaptive Access Manager

This section contains information on installing and setting up OAAM.

To setup Oracle Adaptive Access Manager

  1. Set up OAAM by importing snapshots.

    See Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager for details.

  2. Integrate OAAM and Access Manager as documented in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager.

    The TAP token version must be v2.1 and not v2.0.

  3. Ensure that the following properties are set to true.

    • oracle.oaam.idcontext.enabled is true by default; use the OAAM Administration Console to change the value.

    • bharosa.uio.default.registerdevice.enabled must be true for proper operation of the 'safeforuser' claim.

  4. From the OAAM Administration Console, go to Properties, Create New Property.

  5. Enter the property name oaam.uio.oam.dap_token.version with a value equal to v2.1.

  6. Restart oaam_server_server1.

41.5.3.2 Configuring Access Manager for OAAM Integration

Perform the following steps. Using the TAPScheme forces the user to authenticate using the OAAM authentication schemes.

Note:

Do not use OAAM Advanced or OAAM Basic.

To configure Access Manager for Integration with OAAM Integration

  1. Protect a resource (Defining Authentication Policies for Specific Resources) using the TAPScheme for authentication (Table 16-20).

  2. Add the following challenge parameter to the TAPScheme (Table 16-21):

    TAPOverrideResource=http://IAMSuiteAgent:80/oamTAPAuthenticate

41.5.3.3 Validating Identity Context Data Published by OAAM

The following information describes how you might validate Identity Context data published by OAAM.

  • oracle:idm:claims:risk:newdevice will be true after a login from a new device; false otherwise.

  • oracle:idm:claims:risk:level will have a high value after a couple of unsuccessful logins followed by a successful login. To test for this, try a few unsuccessful logins and then a successful one.

  • oracle:idm:claims:risk:safeforuser will have true after a user successfully answers the challenge question.

  • oracle:idm:claims:risk:fingerprint contains the user's device's fingerprint. By default, the fingerprint built out of HTTP header data is used; if that is not available, fingerprint data built out of Flash will be used. To test for different fingerprints, try different devices.

41.5.4 Configuring Web Service Security Manager

Do the following to enable Oracle Web Service Security Manager (OWSSM) to propagate Identity Context.

To configure Web Service Security Manager for Identity Context

  1. Configure Security Policy by modifying the Identity Context supported OWSSM security policies to contain the propagate.identity.context element with a value of true.

    Note:

    propagate.identity.context (by default, false) is a configuration override property on SAML related policies. To enable it globally, configure a global policy with the property set to true.

  2. Configure the Keystore and Credential Store to sign the SAML assertion and messages: copy the updated Keystore and Credential Store to your domain_home/config/fmwconfig/ directory.

41.5.5 Configuring Oracle Entitlements Server

Runtime integration with Oracle Entitlements Server (OES) is fully automated. When an application invokes the PEP API to make an authorization call, the PEP API automatically propagates the entire Identity Context Runtime to the OES PDP where Conditions (the policy objects that define the Identity Context) are evaluated.

Note:

When making authorization calls, ensure that the last argument passed into the newPepRequest() method is not null, and is at least an empty hashmap as shown in this example: 
PepRequestFactory requestFactory =  
   PepRequestFactoryImpl.getPepRequestFactory();
PepRequest request = requestFactory.newPepRequest (subject, 
   action, resource, new HashMap<String, Object>());
PepResponse response = request.decide();
boolean isAuthorized = response.allowed();

Conditions are built, based on the Identity Context schema, by a security Administrator using the OES Administration Console. The following built-in functions are used to specify Conditions using Identity Context attributes:

  • ASSERT_IDENTITY_CONTEXT

  • GET_STRING_IDENTITY_CONTEXT

  • GET_INTEGER_IDENTITY_CONTEXT

  • GET_BOOLEAN_IDENTITY_CONTEXT

Custom OES functions receive the full Identity Context Runtime information as a well-known request attribute. This data structure can be converted into Identity Context Runtime using the Identity Context API. Example 41-4 shows a custom OES function creating a context from the received parameter.

Example 41-4 Custom Function Creating Identity Context

public OpssString GET_STRING_IDENTITY_CONTEXT_V2 (
 RequestHandle requestHandle,
 Object[] args,
 Subject subject,
 Map roles,
 Resource resource,
 ContextHandler contextHandler) throws RuntimeException {
 
// Obtain string representation of the runtime ID Context from the request handle.
Context runtimeCtx = null; 
 try {
 AttributeElement ctxAttr = requestHandle.getAttribute
  (Constants.IDM_IDC_API_ID, false);
    if (ctxAttr != null) {  
      String ctxStr = (String) ctxAttr.getValue(); 
      runtimeCtx = new Context(ctxStr);
    } else {
      throw new RuntimeException ("Unable to acquire ID Context from request handle");
    }
  } catch (Exception e) {
    throw new RuntimeException (e.toString());
  }
 
…
 
// start using Context which now contains the same exact Identity Context Runtime as was present in the application that made the PEP API call
…
}

41.5.6 Configuring Oracle Enterprise Single Sign On

As part of the Identity Context Service, Oracle Enterprise Single Sign-on (OESSO) can publish and propagate client-based Identity Context attributes. Once full integration has been configured, client-specific Identity Context attributes (as documented in Section 41.3.1, "Using the Identity Context Dictionary") will be sent by OESSO to OAM in the session initiation request together with the user credentials submitted in the access request.

After the request has been received, OESSO makes a call to an SSL-protected OAM REST API (previously configured by the OESSO Administrator and included as part of the OESSO client distribution). This API returns the OAM_ID cookie to OESSO. OESSO then propagates the valid OAM_ID cookie to the client browsers (Internet Explorer and Firefox) which enables OESSO resources to be protected and enables single sign-on (SSO) with those resources that are protected by the OAM Embedded Credential Collector. (This does not include resources that are protected by the Distributed Credential Collector.) OESSO then provides OAM credentials that are acceptable to the OAM Embedded Credential Collector as well as client context information in the payload.

Note:

The payload is secured by:

  • Generating a 16 byte Random Salt

  • Generating a SHA-256 Hash using the 16 Byte Random Salt

  • Encrypting the claims using the OAM password protected by OESSO

To configure OESSO to get attributes for Identity Context

  1. Refer to "Installing Logon Manager Client-Side Software" in the Oracle Enterprise Single Sign-On Suite Plus Installation Guide for details on integrating OAM and OESSO.

  2. See additional details in the Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide section "Oracle Access Management Support in Logon Manager".

41.5.7 Configuring Oracle Access Management Mobile and Social

Oracle Access Management Mobile and Social (Mobile and Social) provides REST-based authentication services, in addition to a user profile service and an authorization service, for mobile and desktop devices. When Mobile and Social is configured to provide authentication using Access Manager, it can publish Identity Context attributes provided by the mobile client to Access Manager. The Identity Context attributes are published by the Mobile and Social SDK for iOS and Java platforms.

Mobile applications use the Mobile and Social SDK to access and use services provided by the Mobile and Social server. When a mobile application uses the iOS or Android API to perform authentication, it captures the Identity Context attributes and publishes the data to the Mobile and Social server which, in turn, publishes the attributes to the Access Manager server. The Administrator can configure the Mobile and Social server to get all the attributes or only the required ones.

The Administrator configures the Identity Context attributes to be sent by the application in the Application Profile configuration page of the Mobile and Social accordion under the System Configuration tab in the Access Manager Administration Console.

The Mobile and Social server passes the required Identity Context attributes to the Mobile and Social SDK when it contacts the server for the application profile. (An application profile has information regarding the type of authentication to be performed as well as the Identity Context attributes to be collected.) The SDK collects the attributes, if allowed by the user or the platform, and publishes them to the Mobile and Social server as part of the authentication request.

Note:

Some mobile platforms (iOS, for example) forbid applications from collecting certain device attributes (for example, the UDID or IMEI device number). The user can also deny an application from getting a location update. Thus, even if the server requests attributes, it is not guaranteed that all of them can be collected by the SDK.

To configure the Mobile and Social server to publish the attributes collected from the Mobile and Social SDK to the user session created on and maintained by the OAM Server, the administrator must configure Mobile and Social server to enable ID Context, as illustrated in Figure 41-4.

Figure 41-4 OAM Authentication Provider Configuration

Surrounding text describes Figure 41-4 .

To configure Mobile and Social to get attributes for Identity Context

  1. Confirm that the Mobile and Social Service is enabled as described in "Enabling or Disabling Available Services".

  2. On the MobileOAMAuthentication Service Provider page, add the IDContextEnabled Attribute with the value of true.

See Also:

  • Chapter 38, "Configuring Mobile Services" for full configuration details

  • Oracle Fusion Middleware Developer's Guide for Oracle Access Management for details on how to develop applications using the iOS SDK

41.6 Validating Identity Context

Use the following procedure to ensure correct operation of the Identity Context with Access Manager.

To validate your Identity Context operations

  1. Perform the following to validate the Identity Assertion response that Access Manager is constructing.

    1. Configure Access Manager to protect the /testidc resource with a WebGate agent and return the Identity Assertion with the desired Asserted Attributes as part of the Authorization response.

    2. Use the OAM Tester to validate that the Identity Assertion is returned as an OAM_IDENTITY_ASSERTION attribute in response to the authorization request for /testidc.

  2. Perform the following to validate that WebGate is creating an HTTP header that contains the Identity Assertion.

    1. Ensure the /cgi-bin/printenv.pl script is protected by the same policy that protects the /testidc resource.

      Note:

      printenv.pl ships as part of OHS and must have permission to execute. Any script to display header information can be used instead.

    2. Access the printenv.pl to trigger a login and display the HTTP headers.

    3. Ensure that the HTTP_OAM_IDENTITY_ASSERTION header contains a SAML token with Asserted Attributes.