This topic provides a comparison against the 10g architecture for Access Manager and OSSO.
Included are the following topics:
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:
Table 30-2 Comparison: Access Manager 11g versus 10g
Feature | Access Manager 11g | 10g |
---|---|---|
Agents |
Note: Nine Administrator languages are supported. |
Note: Nine Administrator languages are supported. |
Server-side components |
|
|
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 |
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 |
|
Global shared secret stored in the directory server only (not accessible to WebGate) |
Cookies |
Host-based authentication cookie. See Table 1-2 |
|
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:
|
|
Session Management |
|
|
Client IP |
|
|
Response token replay prevention |
|
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.
|
Centralized log-out |
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.
|
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 |
|
|
Host identifiers |
|
|
Authentication 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:
|
|
Cookies |
See Also: Table 21-6 and |
See Also: Table 21-6 and |
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:
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 |