Home‎ > ‎Oracle Access Manager‎ > ‎Architecture‎ > ‎

Security


Oracle Access Manager has a lot of security features in place to authenticate, authorize users and secure data in transit and at rest. 

OAM Roles and Delegated Administration

Delegating administration allows a high-level administrator to grant responsibilities to other, more local administrators. In OAM, there are two type of Administrators that a user or group in System Store (typically a directory, default embedded LDAP, where system related user and groups are defined and managed) can be assigned to
  1. System Administrator
  2. Application Administrator
  3. Global Admin Role/Domain System Administrator - This is special group which does not appear in UI but it is a super admin role that has full access capability. This administrator role is identified and defined as Global "Admin" role in Weblogic Domain and, by default, is assigned to "Administrators" groups. So, any user with a group that has the "name" Administrators in the System Identity Store will automatically be assigned global admin role/domain system administrator that has few additional capabilities in the OAM UI (See below for details).
Any user that belongs to the role above either directly or through a group (typically an LDAP group defined in system [identity] store directory), would automatically have corresponding level of access. 
  1. All Application and component policy objects (including Resources, Authentication Policies, Authorization Policies, and Token Issuance Policies)
  2. Shared components (including Authentication Schemes, Host Identifiers, and Resource Types)
  3. System configuration (including Common Configuration, Access Manager settings and Authentication Modules, Security Token Service Settings, Custom Tokens, Endpoints, Templates and Profiles, and Access Manager Agents and Security Token Service Partners)
  4. Agents and partners

The users in System administrator role (either directly or through LDAP group hierarchy) can
  1. Grant Application Administrator role to other user and groups. 
      

  2. Grant users/groups in Application Administrator role to specific Application Domain

  3. Manage All Application and component policy objects (including Resources, Authentication Policies, Authorization Policies, and Token Issuance Policies)
  4. Manage Shared components (including Authentication Schemes, Host Identifiers, and Resource Types)
  5. Manage System configuration (including Common Configuration, Access Manager settings and Authentication Modules, Security Token Service Settings, Custom Tokens, Endpoints, Templates and Profiles, and Access Manager Agents and Security Token Service Partners)
  6. Manage Agents and partners
  7. Manage Identity Stores (except setting or editing system identity stores). 
The users in Application administrator role (either directly or through LDAP group hierarchy-> how many level?) can 
  1. Grant users/groups in Application Administrator role to specific Application Domain that they are already assigned to.
  2. Manage Application and component policy objects of Application domains that are assigned to the user (including Resources, Authentication Policies, Authorization Policies, and Token Issuance Policies - see screenshot above)
The screenshot of administration screen for the Application Administrator is available below



The Domain System Administrator (as defined above) is a super administrator that has following capabilities in addition to system administrator role
  1. System Identity Store modification and selection/change of a system identity store

OAM Access Client - Server communication

The OAM Access Client uses proxy port for back channel and proxy related calls to OAM Server. This communication can be made in one of the following mode by the Access Client
  1. Open: Use this unencrypted mode if communication security is not an issue in your deployment.
  2. Simple: Use this Oracle-signed certificate mode if you have some security concerns, such as not wanting to transmit passwords as plain text, but you do not manage your own Certificate Authority (CA).
  3. Cert: Use if you want different certificates on OAM Servers and Webgates and you have access to a trusted third-party CA.
This can be enabled and configured as defined in the Infrastructure Upgrade.

Data Encryption at rest and in motion



Cryptographic keys

Note: One key is generated and used per registered mod_osso or 11g Webgate. However, one single key is generated for all 10g Webgates.


During 11g agent registration, one per-agent secret key shared is generated for encrypting and decrypting SSO cookies between 11g Webgate and OAM Server. See Chapter 16.


During 10g agent registration, a global shared secret key is generated across all of Access Manager 11g (all Agents and OAM Servers). See Chapter 25.


During OSSO agent registration, One key per partner shared between mod_osso and OSSO server. See Chapter 24.


OpenSSO Agent Host- or Domain-based key stored locally in Agent bootstrap file on the Agent host. See Chapter 23.


During OAM Server registration, one server key is generated.










Keys storage


Agent side: A per-agent key is stored locally in the Oracle Secret Store in a wallet file


OAM Server side: Per- agent keys, and server keys, are stored in the credential store on the server side








Encryption / Decryption (The process of converting encrypted data back into its original form)

Introduces client-side cryptography and ensures that cryptography is performed at both the agent and server ends:


Webgate encrypts obrareq.cgi using the agent key.

Note: obrareq.cgi is the authentication request in the form of a query string redirected from Webgate to OAM Server.


OAM Server decrypts the request, authenticates, creates the session, and sets the server cookie.


OAM Server also generates the authentication token for the agent (encrypted using the agent key), packs it in obrar.cgi with a session token (if using cookie-based session management), authentication token and other parameters, then encrypts obrar.cgi using the agent key.

Note: obrar.cgi is the authentication response string redirected from the OAM Server to Webgate.


Webgate decrypts obrar.cgi, extracts the authentication token, and sets a host-based cookie.



----->>>> Certification revocation (esp. for STS) managed through the 


Attack prevention




Client IP


Maintains this client's age, and includes it in the host-based cookie: OAMAuthnCookie for 11g Webgate (or ObSSOCookie for 10g Webgate)








Response token replay prevention


Include RequestTime (the timestamp just before redirect) in obrareq.cgi and copy it to obrar.cgi (the authentication response string redirected from the OAM Server to Webgate) to prevent response token replay.


OAM Console Authentication.


A single default LDAP group, the WebLogic Server Administrators group, is set in the Default User Identity Store (Embedded LDAP) designated as the System Store. The LDAP group, when assigned to a specified user, grants full system and policy configuration privileges. Specifying a different LDAP group prohibits WebLogic Administrators from logging in to Oracle Access Management Console or from using administrative command-line tools.


During initial deployment with the Oracle Fusion Middleware Configuration Wizard, the Administrator userID and password are set. These credentials grant access to the:

Oracle Access Management Console to register and manage system configurations, security elements, and policies.

WebLogic Server Administration Console to view the Summary of Server Configuration (Cluster, Machine, State, Health, and Listening Port) of deployed OAM Servers within the WebLogic Server domain, and also to Start, Resume, Suspend, Shutdown, or Restart SSL on these servers. See the WebLogic Server Administration Console, see Oracle Fusion Middleware Administrator's Guide for more information.

Custom Administrative command-line tools (including the WebLogic Scripting Tool and Remote Registration Tool) provide an alternative to the Oracle Access Management Console for a specific set of functions. See Section 2.4, "Configuring with the Command-Line Tools" for more information.

Initially, administrative users must log in to the Oracle Access Management Console using the WebLogic Administrator credentials set during initial configuration. However, your enterprise might require independent sets of Administrators: one set of users responsible for Oracle Access Management administration and a different set for WebLogic administration. For information on this, see "Managing the Administrators Role".


Cookies

OAM_LANG_PREF Cookie

ParametersDescription

Name

OAM_LANG_PREF

Domain

Domain-scoped cookie

Path

/

Value

[Cookie version] [separator] [UTF-8 BASE64(name-value pairs)]

For example:

v1.0~kqhkiG9w0BAQQFADCB0TELM

ExpirationTime

Persistent | Session (default) – Specified in OAM configuration

Secure Flag

No

preferredLanguage

BCP47/RFC4647. Specifically, the value space should conform to what is formally called the "language priority list".

defaultLanguageMarker

true (reconcile cookie with application maintained preferences) |false (read from cookie).

Cookie Lifecycle

Oracle Access Management and other applications can perform create, read, update, and delete operations.