Sharing user details

able 2-8 Application Integration for Language Preference


HTTP Accept-Language Header

This enables application to integration without code change. This is a major advantage over the other options. We can expect this to be good for most applications that respond to the browser locale setting. This is the standard practice in internationalizing a Web application. We expect this to be able to become the standard option for all ADF based products, as well as any application that responds to browser locale.

Note: OAM Agents ensure that the Accept-Language reflects the language selected. Also, ServletFilters could be used to make this happen.

Access Manager Policy Response

Access Manager stores the language selection in the attribute langPref in the session namespace. For instance: $session.langPref.

This attribute can be passed to downstream applications using an HTTP Header and/or Cookie through the Access Manager Policy Response. The name of the Header and/or Cookie is a deployment time assignment.

Preference Cookie

When the language selected during login differs from the value stored in the Preference Cookie, Oracle Access Management will update the "preferredLanaguage" parameter in the Preference Cookie with the newly selected language and set the defaultLanguageMarker" parameter to "false".


The language preference can be propagated as a custom claim in the IdentityContext. Select "oracle:idm:claims:session:attributes" as the claim name and then specify the session attribute using the following notation: "preferredLanguage=$session.langPref.

The claim will be created with the name of "oracle:idm:claims:session:attributes:preferredLanguage" and value equal to the session'slangPref attribute.

OAM_REMOTE_USER header, a second OAM_IDENTITY_DOMAIN are used to provide the login user name and associated domain to backend application.