Archive for the ‘Oracle Access Manager’ Category

Single Sign-on and the OBSSOCookie

July 13, 2009

The Oracle Access System implements single-domain and multi-domain single sign-on
through an encrypted cookie called the ObSSOCookie. The WebGate sends the
ObSSOCookie to the user’s browser upon successful authentication. This cookie can
then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.

When the user requests access to a browser or another resource, the request flows to
the Access Server. The user is logged in, and the ObSSOCookie is set. The Access
Server generates a session token with a URL that contains the ObSSOCookie. Single
sign-on works when the cookie is used for subsequent authorizations in lieu of
prompting the user to supply authorization credentials.

When the cookie is generated, part of the cookie is used as an encrypted session token.

The encrypted session token contains the following information:
– The distinguished name (DN) of the authenticated user.
– The level of the authentication scheme that authenticated the user.
– The IP address of the client to which the cookie was issued.
– The time the cookie was originally issued.
– The time the cookie was last updated.

If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter.

Unencrypted ObSSOCookie data includes:
– Cookie expiry time.
– The domain in which the cookie is valid.
– An optional flag that determines if the cookie can only be sent using SSL.
Security of the ObSSOCookie

The ObSSOCookie is a secure mechanism for user authentication. When the Access
System generates the cookie, an MD-5 hash is taken of the session token. When the
ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the
original cookie contents to be sure no one has tampered with the cookie. MD-5 is a
one-way hash, so it cannot be unencrypted. The Access Server does the comparison by
hashing the session token again and comparing the output with the hash of the token
already present in the cookie. If the two hashes do not match, the cookie is corrupt.
The system relies on the fact that if someone tampers with the session token, the
hashes will not match.

The single sign-on cookie does not contain user credentials such as user name and
password.


Courtesy:http://identitymanagement1.blogspot.com/
Advertisements

Credential Mapping Error – Oracle Access Manager

July 13, 2009

Setting up IWA is a fairly straight forward task. All you need are an OAM environment, an IIS server with WebGate installed and special IWA Authentication Scheme. The IWA specific authentication scheme requires a credential mapping plugin to map the REMOTE_USER HTTP header variable set by IIS to a user attribute in the OAM user directory. WebGate even takes care of parsing the domain name from REMOTE_USER for you, what could be easier?

So assuming you followed all of hte instructions and everything is set up perfectly, or at least you think it is, what do you do if you still have a problem. Specifically, what could be wrong if are getting a credential mapping error in the web browser and the access server oblog.log file.

I recently encountered just such a problem. I used the search base and filter from the credential mapping plugin and conducted my own search against the directory as the OAM service account and it worked perfectly. This was so puzzling. I looked for trailing spaces in the credential mapping plugin because I know that can occur with resource patterns and ldap urls in other parts of Policy Manager. I finally compared a working credential mapping plugin to the IWA one. The different was in the quotation marks. The IWA credential mapping had been copied and pasted from the Metalink article discussing how to set up IWA in OAM. They were obviously from the wrong character set. Replacing the quotation marks solved the problem.


Courtesy:http://coreidng.blogspot.com/

Authentication Steps in Oracle Access Manager 10ред1.4

June 14, 2007

Authentication Steps in Oracle Access Manager 10.1.4

1. HTTP request
2. AccessGate: Is the resource protected?
3. AccessServer: checks the directory server for policy
4. Directory Server responds to Access Server
5. Access Sever responds to WebGate with policy information
6. WebGate presents the Challenge
7. User Credentials to Access Gate
8. AccessGate passes Credentials to Access Server
9. Access Server calls one or more authentication plug-ins
10. Access Server checks directory server for DN.
11. Directory Server responds with zero or 1 dn.
12. Access Server responds to Access Gate
13. Successful Authentication
14. Encrypted Cookie Set for browser
15. Is the user authorized? What are associated actions?
16. Access Server checks directory server for policy
17. Directory Server responds to Access Server
18. Access Server responds to WebGate with policy information
19. Returns requested resource.

Oracle Access Manager FAQ

June 13, 2007

FAQ’S on OAM 10g3