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

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

Note:

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

55.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 55-1 documents these default attributes. The following list provides details on the end-to-end flow of the Identity Context Runtime. Figure 55-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 55-3 Identity Context Process Flow

Description of "Figure 55-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 55-2 documents which Access Management platform products do what when working with Identity Context.

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

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.