55.5 Configuring the Identity Context Service Components

Each Identity Context Service component must be configured to accommodate business requirements. Support for Identity Context is pre-integrated into each participating Oracle Access Management component. A high-level overview of the necessary Identity Context configurations is provided here. However, detailed information can be found in documentation accompanying individual products.

See Table 55-2

This section describes the following topics:

55.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.

55.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.

55.5.2.1 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.

55.5.2.2 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").

55.5.2.3 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.

55.5.2.4 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.

55.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 55-1. OAM then pushes these attributes into the $session.risk.attr namespace. The following sections contain information regarding configuration of OAAM and OAM.

55.5.3.1 Setting Up Oracle Adaptive Access Manager

You can install and set up Oracle Adaptive Access Manager.

This section contains information on installing and setting up OAAM.

To setup Oracle Adaptive Access Manager

Set up OAAM by importing snapshots.

See for details.
Integrate OAAM and Access Manager as documented in the .

The TAP token version must be v2.1 and not v2.0.
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.
From the OAAM Administration Console, go to Properties, Create New Property.
Enter the property name oaam.uio.oam.dap_token.version with a value equal to v2.1.
Restart oaam_server_server1.

55.5.3.2 Configuring Access Manager for OAAM Integration

You can configure Access Manager for the Integration with OAAM.

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

Protect a resource (Defining Authentication Policies for Specific Resources) using the TAPScheme for authentication (Table 22-21).
Add the following challenge parameter to the TAPScheme (Table 22-22):
```
TAPOverrideResource=http://IAMSuiteAgent:80/oamTAPAuthenticate
```

55.5.3.3 Validating Identity Context Data Published by OAAM

You might validate Identity Context data published by OAAM.

To validate:

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.

55.5.4 Configuring Web Service Security Manager

You can enable Oracle Web Service Security Manager (OWSSM) to propagate Identity Context.

To configure Web Service Security Manager for Identity Context:

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.
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.

55.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. The following example shows a custom OES function creating a context from the received parameter.

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
…
}

55.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 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

Refer to "Installing Logon Manager Client-Side Software" in the for details on integrating OAM and OESSO.
See additional details in the section "Oracle Access Management Support in Logon Manager".

55.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 55-4.

Figure 55-4 OAM Authentication Provider Configuration

Description of "Figure 55-4 OAM Authentication Provider Configuration"

To configure Mobile and Social to get attributes for Identity Context

Confirm that the Mobile and Social Service is enabled as described in "Available Services of the Common Configuration Section".
On the MobileOAMAuthentication Service Provider page, add the IDContextEnabled Attribute with the value of true.