42 Using Identity Context

42.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 42-1 documents the Schema attributes.

Note:

Virtual attributes (as documented in Table 42-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.

42.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 42-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 42-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 42-3 Identity Context Process Flow

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 42-2 documents which Access Management platform products do what when working with Identity Context.

42.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 42-2).

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

• Configuring Identity Assertion

• Configuring Federation Attributes

• Configuring Session Attributes

• Configuring Identity Store Attributes

42.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 18-11).

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

• Setting Up Oracle Adaptive Access Manager

• Configuring Access Manager for OAAM Integration

• Validating Identity Context Data Published by OAAM

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

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

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 42-4 shows a custom OES function creating a context from the received parameter.

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

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

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

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

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

Figure 42-4 OAM Authentication Provider Configuration

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.