Difference Between – OAM 11g versus OAM 10g versus OSSO 10g

OAM 11g OAM 10g OSSO 10g
Architecture Components
  • Agents: Webgate, Access Client, mod_osso, and IAMSuiteAgent
  • OAM Server
  • Oracle Access Manager Console (installed on WebLogic Administration Server)

Note: Eight Administrator languages are supported.

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

Note: Eight Administrator languages are supported.

  • mod_osso (partner)
  • OracleAS SSO server (OSSO server)
Cookies Host-based authentication cookie:

  • 11g Webgate, One per agent: OAMAuthnCookie_<host:port>_<random number> set by Webgate using the authentication token received from the OAM Server after successful authentication.

    Note: A valid OAMAuthnCookie is required for a session.

  • 10g Webgate, One ObSSOCookie for all 10g Webgates.
  • One for the OAM Server: OAM_ID
  • Domain-based ObSSOCookie for Webgates (including the AWG), for both authentication and session management
  • Host-based authentication cookie:

    one per partner: OHS-host-port

    one for OSSO server: (but not with OAM 11g)

  • Domain-level session cookie for global inactivity timeout (GITO) if enabled (for inter-operability with OAM 11g)
Cryptographic keys

The protocols used to secure information exchange on the Internet.

  • One per agent secret key shared between Webgate and OAM Server
  • One OAM Server key
One global shared secret key for all Webgates
  • One key per partner shared between mod_osso and OSSO server
  • OSSO server’s own key
  • One global key per OSSO setup for the GITO domain cookie
Key storage
  • Agent side: A per agent key is stored locally in the Oracle Secret Store
  • OAM 11g server side: A per agent key, and server key, are stored in the credential store on the server side
Global shared secret stored in the directory server only (not accessible to Webgate)
  • mod_osso side: partner keys and GITO global key stored locally in obfuscated configuration file
  • OSSO server side: partner keys, GITO global key, and server key are all stored in the directory server
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 11g 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.
Cryptography is performed at both mod_osso and OSSO server:

  1. site2pstore token (request from mod_osso to server) is encrypted using the partner key locally at mod_osso.
  2. OSSO server decrypts site2pstore token, authenticates, and generates its own cookie.
  3. urlc token (the response from OSSO server to mod_osso) is encrypted using the partner key at the server.
  4. mod_osso decrypts the urlc token locally and re-encrypts using its own format to set in a host-based cookie.
Session Management
  • OAM 10g session idle timeout behavior is supported through the 11g Session Management Engine (SME). Session states are retained in memory
  • 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.

  • Single domain supported through a domain-level cookie for global inactivity timeout (GITO).

    Multi-domain SSO: After a user logs in to one domain, and then goes to a different domain, he is considered idle from the first domain, When the idle times out on the original domain, the user must re-authenticate on the original domain.

Client IP
  • Maintain this ClientIP, and include it in the host- based OAMAuthnCookie.
  • Include the original clientIP inside the ObSSOCookie.

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

    Rejection occurs if there is no match

  • Include the original clientIP inside the host cookie.

    In later authentication requests, when the cookie is presented, the original clientIP 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
  • Include RequestTime (timestamp just before redirect) in the site2pstore token and copy it to the urlc token to prevent token replay.
Centralized log-out
  • The logOutUrls (OAM 10g Webgate configuration parameter) is preserved.
  • New 11g Webgate parameters are provided:

    logoutRedirectUrl

    logoutCallbackUrl

    Logout Target URL

For more information, see Chapter 15.

  • 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.
The OSSO server cookie includes a list of partner IDs.

When a user logs off from one partner application:

  1. OSSO server pulls a list of the logout URLs.
  2. OSSO server clears its own cookie.
  3. OSSO server redirects to a customized JSP page (hosted on the OSSO server), and passes the list of logout URLs in the request.
  4. The JSP page loads those logout URLs that contains some image tags of check marks, and as a result of the loading, the cookies for those mod_osso instances are cleared

Leave a Reply

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