Using Identity Context

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

This section describes the following topics:

42.1 Introducing Identity Context

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.

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

42.2 Understanding Identity Context

Access Manager enables context-aware access management by incorporating Identity Context as a built-in service of the Oracle Access Management platform.

Figure 42-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 42-1 End to End Identity Context Process

Description of "Figure 42-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 42-2 illustrates the functional architecture of Identity Context based on the Oracle applications of which it is comprised.

Figure 42-2 End To End Identity Context Process Components

Description of "Figure 42-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.

42.3 Working With the Identity Context Service

The Oracle Access Management platform enables Identity Context data to be collected, propagated across the involved components, and made available for granting or denying authorization to access protected resources.

For more information, see Figure 42-2. 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.

This section describes the following topics:

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

Table 42-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: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.)

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

User accesses a protected application from a device.
Access Manager asserts the identity, collects Identity Attributes from the participating Access Management publishing components and creates an Identity Context.
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.
The protected application calls the OES PEP API to make an authorization decision. OES automatically propagates the Identity Context to the local OES PDP.
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.
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.
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.
Web Service application calls OES PEP API to make an authorization decision.
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

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

Table 42-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 and OESSO determines whether or not the client device has a firewall enabled.	OAM – Session, Federation, and identity store 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, 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 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.

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 and OESSO determines whether or not the client device has a firewall enabled.

OAM – Session, Federation, and identity store 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, 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 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.

42.4 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). The following example illustrates an application working with Identity Context Dictionary.

Exmaple 55-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. The following example demonstrates how to use WLST to grant the OPSS Attribute Service permission to access an application (in this case, ssofilter.jar).

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()

The following example illustrates an application working with Identity Context Runtime.

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
}

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

This section describes the following topics:

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.

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.

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

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

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

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

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

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

42.5.5 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 Oracle Enterprise Single Sign-On Suite Plus Installation Guide for details on integrating OAM and OESSO.
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.6 Configuring Secure Identity Context Propagation

The OAM_IDENTITY_ASSERTION header is used to securely propagate the Identity of the end user to the OAM protected application. The value of the OAM_IDENTITY_ASSERTION header is a Base64 encoded signed SAML token containing the Identity Context. By default, the token is signed using a Self Signed Certificate generated during bootstrap when the Server was started for the first time. The signing key and certificate are stored in the OAM Keystore at $DOMAIN_HOME/config/fmwconfig/.oamkeystore.

This section provides steps to replace the out of the box signing key and certificate. It is recommended that you use a key and certificate issued in compliance with your enterprise security practices.

Note:

It is recommended that you take a backup of the latest .oamkeystore under the name .oamkeystore_new before updating the .oamkeystore.

For example, domain home: <mw>/domains/oam_domain

Run the following commands to create certificate and key:

openssl req -new -keyout aaa_key.pem -out aaa_req.pem -utf8 -sha256

Note:
The key must be generated using the same password as the .oamkeystore file.
openssl genrsa -aes256 -out rootCA.key 4096
openssl req -x509 -new -nodes -key rootCA.key -days 7300 -sha256 -out aaa_chain.pem
openssl x509 -req -in aaa_req.pem -CA aaa_chain.pem -CAkey rootCA.key -CAcreateserial -sha256 -out aaa_cert.pem -days 500
openssl x509 -in aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
openssl pkcs8 -topk8 -nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der -outform DER

Run the following keytool commands to update the .oamkeystore:

keytool -delete -alias assertion-cert -v -keystore oamkeystore_new-storepass <pswd> -storetype JCEKS
keytool -delete -alias assertion-key -v -keystore oamkeystore_new-storepass <pswd> -storetype JCEKS
keytool -list -v -keystore oamkeystore_new -storetype JCEKS -storepass <pswd>
keytool -importcert -file aaa_chain.pem -trustcacerts -storepass <pswd> -keystore oamkeystore_new -storetype JCEKS -alias assertion-cert
keytool -list -v -keystore oamkeystore_new -storetype JCEKS -storepass <pswd>
<JDK>/bin/java -cp importcert.jaroracle.security.am.common.tools.import certs.CertificateImport -keystoreoamkeystore_new -privatekeyfile aaa_key.der -signedcertfile aaa_cert.der -alias assertion-key -storetype JCEKS
keytool -list -v -keystore oamkeystore_new -storetype JCEKS -storepass <pswd>
Copy the oamkeystore_new to the location
<DOMAIN_HOME>/config/fmwconfig/.oamkeystore cp oamkeystore_new <DOMAIN_HOME>/config/fmwconfig/.oamkeystore
keytool -list -v -keystore <DOMAIN_HOME>/config/fmwconfig/.oamkeystore -storetype JCEKS -storepass <pswd>
WLST command to save artifacts:
saveAccessArtifacts(domainHome="<mw>/domains/oam_domain", propsFile="<path>/dbprop.properties")

Note:
Content of <path>/dbprop.properties:
oam.entityStore.schemaUser=OAM_Schema_userName

oam.entityStore.schemaPassword=<pswd>

oam.entityStore.ConnectString=jdbc:oracle:thin:@dbhost:dbport/ServiceID

Once you have updated your Signing Certificate, you should update your Clients to use the updated Certificate to validate the OAM_IDENTITY_ASSERTION header value. If you are using the Weblogic OAM Identity Asserter (OAMIdentityAsserter), then you must replace the validation certificate in the configuration.

For more information, see Integrating Oracle ADF Applications with Access Manager SSO.

42.6 Validating Identity Context

You can ensure correct operation of the Identity Context with Access Manager.

To validate:

To validate your Identity Context operations

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