Access Manager 11g difiere de 10g en que las funciones de administración de identidad han sido transferidos a Oracle Identity Manager 11g (incluyendo auto-servicio y auto-registro de usuario, flujos de trabajo, gestión dinámica de grupos, y administración de identidad delegada).

Access Manager 10g soporta Single Sign-On usando una cookie de sesión única (el ObSSOCookie), esta contiene la información de identidad de usuario y la sesión requerida para acceder a los recursos de destino que tenían el mismo o menor nivel de autenticación. El ObSSOCookie es cifrado y descifrado usando una clave secreta compartida global, cuyo valor se almacena en el servidor de directorios. El ObSSOCookie es consumida por los componentes del sistema de acceso para verificar la identidad del usuario y permitir o no permitir el acceso a los recursos protegidos.

Para cerrar todas las posibles brechas de seguridad, Oracle Access Manager 11g proporciona nuevos componentes de servidor que mantienen la compatibilidad con los agentes existentes de Access Manager 10g (Webgates) y agentes OSSO (10g) mod_osso. El nuevo Oracle Access Manager 11g Webgates es una versión mejorada de Webgates 10g, el cuál soporta una clave secreta por cada agente para la solución de Single Sign-On (SSO). De este modo, se evita el tipo de ataque “cookie-replay”. Los Webgates 11g son todos confiables en el mismo nivel; un cookie específico para un Webgate  no se puede utilizar para acceder a otras aplicaciones protegidas por Webgate en nombre de ese usuario.

A menos que se indique expresamente, el término “Webgate” se refiere tanto a un Webgate “out of the box” o a un cliente personalizado de acceso.

Para ver más detalles sobre las diferencias entre OAM 11g y 10g puedes leer la siguiente tabla de la documentación de Oracle (en inglés):

Access Manager 11g 10g
Agents
  • Agents: Webgate, Access Client, OpenSSO, OSSO (mod_osso), IAMSuiteAgent

Note: Eight Administrator languages are supported.

  • Resource Webgate (RWG)
  • Authentication Webgate (AWG)
  • AccessGate
  • Access Server
  • Policy Manager
  • Identity System

Note: Eight 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, described in Table 1-3, “Introduction: Access Manager 11.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 URLLogout Callback URLLogout Target URL

See Chapter 19.

logout.html requires specific details when using a 10g Webgate with Access Manager 11g. See Chapter 19.

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

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *