30.3 Comparing Access Manager 11.1.2 and 10g

This topic provides a comparison against the 10g architecture for Access Manager and OSSO.

Included are the following topics:

30.3.1 Comparing Access Manager 11g versus 10g

Access Manager 11g differs from 10g in that the identity administration features have been transferred to Oracle Identity Manager 11g (including user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration).

Access Manager 10g supported Single Sign-on using a single session cookie (the ObSSOCookie) that contained the user identity and session information required to access target resources that had the same or lower authentication level. The ObSSOCookie was encrypted and decrypted using a global shared secret key, the value of which was stored in the directory server. The ObSSOCookie was consumed by Access System components to verify the user identity and allow or disallow access to protected resources.

To close any possible security gaps, Access Manager 11g provides new server-side components that maintain backward compatibility with existing Access Manager 10g policy-enforcement agents (WebGates) and OSSO 10g agents (mod_osso). New Access Manager 11g WebGates are enhanced versions of 10g WebGates, that support a per-agent secret key for the Single Sign-on (SSO) solution. Thus, cookie-replay type of attack are prevented. The 11g WebGates are all trusted at the same level; a cookie specific for the WebGate is set and cannot be used to access any other WebGate-protected applications on a user's behalf.

Unless explicitly stated, the term WebGate refers to both an out of the box WebGate or a custom Access Client.

Access Manager 11g uses technology from Oracle Coherence to provide centralized, distributed, and reliable session management.

Table 30-2 provides a comparison of Access Manager 11g versus 10g.

For a list of names that have changed with Access Manager 11g:

See Product and Component Name Changes with 11.1.2

Table 30-2 Comparison: Access Manager 11g versus 10g

Feature Access Manager 11g 10g

Agents

  • Agents: WebGate, Access Client, OpenSSO, OSSO (mod_osso), IAMSuiteAgent

Note: Nine Administrator languages are supported.

  • Resource WebGate (RWG)

  • Authentication WebGate (AWG)

  • AccessGate

  • Access Server

  • Policy Manager

  • Identity System

Note: Nine Administrator languages are supported.

Server-side components

  • OAM Server (installed on a WebLogic Managed Sever)

    Security Token Service and Identity Federation run on OAM Server

  • Access Server

  • Policy Manager

  • Identity Server

Console

Oracle Access Management Console

Access System Console

Identity System Console

Protocols that secure information exchange on the Internet

Front channel protocols exchanged between Agent and Server: HTTP/HTTPS.

11g WebGate secures information exchange using the Agent key.

-See Also: Cryptographic keys.

10g Agent information exchange is unsecured, in plain text.

Cryptographic keys

  • One per-agent secret key shared between 11g WebGate and OAM Server

  • One OAM Server key, generated during Server registration

Note: One key is generated and used per registered mod_osso agent.

One global shared secret key per Access Manager deployment which is used by all the 10g WebGates

Keys storage

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

  • OAM Server side: A per- agent key, and server key, are stored in the credential store on the server side

  • Security Token Service

Global shared secret stored in the directory server only (not accessible to WebGate)

Cookies

Host-based authentication cookie.

See Table 1-2

  • One domain-based ObSSOCookie for all WebGates (including the AWG), for both authentication and session management

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:

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

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

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

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

  • Token generation/ encryption, and validation/ decryption are delegated to the Access Server.

  • Both obrareq.cgi and obrar.cgi are sent unencrypted, relying on the underlying HTTP(S) transport for security.

Session Management

  • Single domain supported.

    Multi-domain: If a user idles out on one domain, but not on the authentication WebGate, the AWG cookie is still valid (re-authentication is not needed).A new cookie is generated with the refreshed timeout.

Client IP

  • Maintain this Client IP, and include it in the host- based OAMAuthnCookie.

  • Include the original client IP inside the ObSSOCookie.

    If IP validation is configured, when cookie presented in later authentication or authorization requests this original client IP is compared with the presenter's IP.

    Rejection occurs if there is no match

Response token replay prevention

  • Include RequestTime (the timestamp just before redirect) in obrareq.cgi and copy it to obrar.cgi to prevent response token replay.

N/A

Multiple network domain support

Cross-network-domain single sign-on out of the box.

Oracle recommends you use Oracle Federation for multiple network domain support.

A proprietary multiple network domain SSO capability predates Oracle Access Management Identity Federation. If this is implemented in your 10g deployment, register 10g Agents with Access Manager 11g to continue this support.

  • Single domain is supported.

    Once a user logs off from one WebGate, the domain cookie is cleared and the user is considered to be logged off the entire domain.

  • Multi-domain SSO can be supported through chained customized logout pages.

Centralized log-out

  • The logOutUrls (10g WebGate configuration parameter) is preserved. 10g logout.html requires specific details for Access Manager 11g.

  • 11g WebGate parameters are new: Logout Redirect URL

    Logout Callback URL

    Logout Target URL

See Configuring Centralized Logout for 11g WebGates.

See

logout.html requires specific details when using a 10g WebGate with Access Manager 11g.

See Configuring Centralized Logout for 11g WebGates.

  • Single domain is supported.

    Once a user logs off from one WebGate, the domain cookie is cleared and the user is considered to be logged off the entire domain.

  • Multi-domain SSO can be supported through chained customized logout pages.

30.3.2 Comparing Access Manager 11g versus 10g Policy Model

Access Manager 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access.

Access Manager 10g provides authentication and authorization based on policies within a policy domain. Access Manager 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly denied access to limit the number of WebGate queries to the Access Server.

Table 30-3 compares the Access Manager 11g policy model with the 10g model. Access Manager 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access. In contrast, Access Manager 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly specified access.

Table 30-3 Comparing Access Manager 11g Policy Model versus 10g

Policy Elements 11g Policy Model 10g Policy Model

Policy Authoring

Oracle Access Management Console

Policy Manager

Policy Store

Database

LDAP directory server

Domain

Application Domain

Policy Domain

Resources

  1. No URL prefixes. Resource definitions are treated as complete URLs.

  2. Pattern matching (with limited features) for:

    ' * ' and '...' are supported

  3. Resources need not be unique across domains.

  4. Query-string protection for HTTP URLs.

  5. Each HTTP resource is defined as a URL path, and associated with a host identifier. However, resources of other types are associated with a specific name (not a host identifier).

  6. Non-HTTP resource types are supported, with definition of specific operations. Non-HTTP resource types are never associated with a host identifier.

  7. Resources can designated as either Protected, Unprotected, or Excluded.

  8. Custom resource types are allowed.

  1. URL prefixes are defined in domains

  2. Pattern matching for:

    { } * …

  3. Resources need not be unique across domains.

  4. http resources can be protected based on URL query string contents and/or HTTP operation.

  5. Non-HTTP resource types and operations can be defined.

Host identifiers

  1. Host Identifiers are defined outside of policies and are used while defining HTTP resources.

  2. Host Identifiers are mandatory for defining HTTP resources.

  1. Host Identifiers are defined outside of policies and are used while defining HTTP resources.

  2. Host Identifiers are not mandatory, for defining HTTP resources, till there are no Host Identifiers defined in the system.

Authentication Policies

  1. Authentication policies include resources, success responses, and an authentication scheme.

  2. Authorization policies can also contain success responses, and time based, IP based and user-based conditions.

  3. Only one authentication policy and one authorization policy can be associated with any resource.

  4. Authentication and Authorization policies can evaluate to Success or Failure.

  5. No Query Builder and no support for LDAP filters for (for retrieving matches based on an attribute of a certain display type, for example).

  6. There is no notion of a default policy in an Application Domain. However, you can define a policy for resource: /…/* which can be used as a default policy within a determined scope).

  7. Token Issuance Policies can be defined using resources and user- or partner-based conditions.

    See Token Issuance Policy Pages.

  1. Authentication policies are simple and contain only authentication-scheme-based rule.

  2. One resource can be associated with a set of Authorization policies. Evaluation of these policies can be based on an expression that combines the policies within the set using logical operators as desired.

    A resource can also be associated with multiple authentication policies and authorization policy sets. However, only one set applies.

  3. An Authorization policy can evaluate to Success or Failure, or Inconclusive.

  4. Users can be specified using LDAP filters.

  5. Default authentication policy and authorization policy set can be defined for a policy domain. This policy is only applicable if there are no other applicable policies for a runtime resource in that domain.

  6. There is no support for Token Issuance Policies.

Authentication Schemes

Authentication Schemes are defined globally and can be shared (referenced within authentication policies).

The trust level is expressed as an integer value between 0 (no trust) and 99 (highest level of trust).

Note: Level 0 is unprotected. Only unprotected resources can be added to an Authentication Policy that uses an authentication scheme at protection level 0.

See Also: .

Authentication Schemes can be defined outside of policies and can be referenced within authentication policies.

Authorization Policy

Each resource assigned to an Application Domain can be protected by only one authorization policy. Each policy can include one or more conditions and a rule.

See Also: Rule, later in this table

See Defining Authentication Policies for Specific Resources.

To protect resources, you define authorization rules that contain one or more conditions.You also configure authorization expressions using one or more authorization rules. A policy domain (and a policy) can each contain only one authorization expression.

Token Issuance Policy

By default, only a container for Token Issuance Policies is provided in a generated Application Domain. No Conditions or Rules are generated automatically. You must add these manually.

See Also: Token Issuance Policy Pages.

N/A

Responses

Available for all policy types:

  1. Authentication and Authorization success Responses can be defined within the policies. These are applied after evaluation of policies.

  2. Cookie, Header, and Session responses are supported.

  3. URL redirection can be set.

  4. Response definitions are part of each policy. Response values can be literal strings or can contain additional embedded expressions that derive values from request, user, and session attributes.

  1. Authentication and Authorization Responses can be defined within the policies for Success, Failure, and Inconclusive events. These are returned to the caller after evaluation of policies.

  2. HTTP_HEADER and Cookie based variables can be set.

  3. Redirect URLs can be set for Success and Failure events of authentication and authorization policy evaluations.

  4. Response values can contain literal strings and list of user attribute values.

Cookies

See Also: Table 21-6

and

Single Sign-On Cookies During User Login

See Also: Table 21-6

and

Single Sign-On Cookies During User Login

Query String-based HTTP Resource Definitions

Supported within Access Policies:

See Table 25-1.

This Policy Model supports query string-based HTTP resource definitions within Access Policies.

At run time, the OAM Proxy passes the Query String to the policy layer after URL encoding, just like for base resource URL. Only Query String that are part of HTTP GET requests are passed. Query String pattern does not apply to HTTP POST data.

Rule

Available for only Authorization and Token Issuance Policies.

Each Authorization policy includes a rule that defines whether the policy allows or denies access to resources protected by the policy.

The rule references Authorization conditions, described next.

See Also: Introduction to Authorization Policy Rules and Conditions.

A policy is defined using authorization rules (among other policy elements). Authorization rules:

  • Are defined outside of policies (but scoped within a policy domain) and are referenced in policies.

  • Appear in two places: 1) as part of default rules for the domain and 2) in policy definitions.

Each rule specifies who (which users, groups or IP4 addresses) is allowed or denied access and the time period in which this rule applies.

There is also a provision to specify whether Allow takes precedence over Deny.

Condition

Available for only Authorization and Token Issuance Policies.

Each Authorization policy rule references conditions that define to whom the rule applies, if there is a time Condition, and how evaluation outcomes are to be applied.

Conditions are declared outside of rules and are referenced within a rule.

See Also: Introduction to Authorization Policy Rules and Conditions.

N/A