Oracle Access Manager Questions and Answers (from onlineappsdba.com website)

Oracle Access Manager Questions & Answers

• February 25, 2010 /
• security     Session     sso /
• By Mahendra /
• 94 COMMENTS

Hi all,

Here I am going to post OAM questions and answers.

Oracle Access Manager is a state-of-the-art solution for both centralized identity management and access control, providing an integrated standards-based solution that delivers authentication, web single sign-on, access policy creation and enforcement, user self-registration and self-service, delegated administration, reporting, and auditing.     

Q: What is Single Sign On?
A: Single Sign-On allows users to sign on once to a protected application and gain access to the other protected resources within the same domain defined with same authentication level.

Q: What is multi domain Single Sign-On?
A:  Multi Domain SSO gives users the ability to access more than one protected resource (URL and Applications), which are scattered across multiple domains with one time authentication.

Q: What is the authentication mechanism used by Oracle Access Manager? 
A: ObSSOCookie and it is stateless.

Q: Explain various security modes present in Oracle Access Manager?
A: 
Open: Allows unencrypted communication. In Open mode, there is no authentication or encryption between the AccessGate and Access Server. The AccessGate does not ask for proof of the Access Server’s identity and the Access Server accepts connections from all AccessGates. Similarly, Identity Server does not require proof of identity from WebPass.
Simple: Supports encryption by Oracle. In Simple mode communications between Web clients (WebPass and Identity Server, Policy Manager and WebPass, and Access Server and WebGate are encrypted using TLS v1. In both Simple and Cert mode, Oracle Access Manager components use X.509 digital certificates only. This includes Cert Authentication between WebGates and the Access Server where the standard cert-decode plug-in  decodes the certificate and passes certificate information to the standard credential_mapping authentication plug-in. For each public key there exists a corresponding private key that Oracle Access Manager stores in the aaa_key.pem file for the Access Server (or ois_key.pem for Identity Server).
Cert: Requires a third-party certificate. Use Cert (SSL) mode if you have an internal Certificate Authority (CA) for processing server certificates. In Cert mode, communication between WebGate and Access Server, and Identity Server and WebPass are encrypted using Transport Layer Security, RFC 2246 (TLS v1).

Q: Explain the architecture of Oracle Access Manager?
A: Oracle Access Manager architecture mainly consists for components such as Identity Server, WebPass, Policy Manager, Access Server and a WebGate. Identity Server is a standalone C++ server which communicates directly with LDAP.
It also receives requests and sends response to Webpass. WebPass is a web server plugin that passes info between identity server and webserver. It redirects HTTP requests from browser to Access Server, and sends Identity XML SOAP requests to Identity Server.
Policy Manager (PMP or PAP) is a web server plugin that communicates directly with user, configuration and policy repositories. Access Server is a stand alone C++ server and is also called PDP. It receives requests from & sends responses to WebGates/AccessGates.
It also communicates with LDAP. It answers Access Server SDK requests. WebGate (PEP) is a web server plugin that passes info between webserver and access server. It passes user authentication data to access server for processing.

Q: What are the ObSSOCookie Contents?
A: Cookie contains encrypted session token and non-encrypted data.
This Encrypted Session Token consists of : DN of the authenticated user, level of auth scheme, ip address of client to which cookie was issued, time the cookie is issued, time the cookie was last updated. If the user is not idle, then cookie will get automatically updated at a fixed interval to prevent session timeout. The updated interval is the 1/4 th of idle session timeout of accessgate.
The Unencrypted ObSSOCookie data contains cookie expiry time, domain in which cookie is valid, additional flag that determines if cookie can only be sent using SSL.

Q: What is the key used for encrypting the ObSSOCookie?
A: Shared Secret key. It is configured in the Identity Admin console and can be generated by the OAM administrator.

Q: What happens if the ObSSOCookie is tampered?
A:  When access system generates ObSSOCookie, MD-5 hash is taken from session token. So when the user is authenticated again using the cookie, the MD5 hash is compared with original cookie contents. MD-5 hash is a one-way hash, hence it cant be unencrypted. Access server compares the cookie contents with hash. If both are not same, then cookie is tampered in the interim. This cookie does not contain username and password.

Q: What is the difference between WebGate and AccessGate?
A: WebGate is an out-of-the-box plug-in that intercepts Web resource (HTTP) requests and forwards them to the Access Server for authentication and authorization. An AccessGate is a custom webgate that can intercept requests of HTTP and non-HTTP resources.
 
Q: What are the major parameters defined in an authentication scheme?
A: The authentication scheme level which defines the level of the security defined for an application.

Q: Explain the flow when a user requests for an application protected by Oracle Access Manager?
A: The following steps describes the flow when a user makes a request to access a resource protected by the Oracle Access Manager.

• User requests for a resource through a web browser.
• The Webgate intercepts the requests and checks with the Access Server whether the resource is protected or not.
• If the resource is not protected, then the user will be shown the requested resource.
• If the resource is protected, then Access Server will check with policy manager the authentication scheme configured for that resource.
• User will be prompted to enter their credentials as per the auth scheme defined for the resource.
• Webgate will send the credentials to the Access Server to check it against the backend (LDAP server).
• Upon successful authentication, Access server checks whether the user is authorized to access the resource or not.
• If the user is authorized, then the Access Server will create the session id and passes it to the webgate. An ObSSOCookie is created and will be sent to the user browser and the user will be shown the requested resource.
• If the user is not authorized, then an error page (if its defined in policy domain) will be shown to the user.

Q: Explain the flow of a Multi domain Single Sign-On?
A: Multi Domain SSO gives users the ability to access more than one protected resource (URL and Applications), which are scattered across multiple domains with one time authentication.

• For multi domain SSO to work, Access Servers in all domains must use same policy directory.
• Multi domain works only with web gates, not Access Gates.
• Within each individual domain, each web gate must have same “primary HTTP cookie domain”.

In Multi Domain SSO environment, we should designate one web server (where web gate is installed) as “Primary Authentication Server”. Primary Authentication Server acts as a central server for all authentications in multi domain environment. In general the webgate installed in the domain where Access server resides will be designated as the primary authentication server.

Lets assume that OAM components are installed in host1.domain1.com and we will designate host1.domain1.com as the primary authentication server.
* Host2.domain2.com with web gate (ex: webgate2) installed.
* A resource, abc.html, is protected with Form base authentication on host1.mydomain1.com
* A resource, xyz.html, is protected with Basic over LDAP authentication on host2.mydomain2.com.

Following are the steps that explain how multi domain SSO works
1. User initiates a request for a Web page from a browser.
For instance, the request could be for host2.mydomain2/xyz.html.
2. Webgate2 (on host2.domain2.com) sends the authentication request back through the user’s browser in  search of primary authentication server.  In this example you have designated host1.domain1.com to be the primary authentication server.
3. The request for authentication is sent from the user’s browser to the primary authentication server, host1.domain1.com.
This request flows to the Access Server. The user logs in with the corresponding authentication scheme and the obSSO cookie is set for host1.domain1.com. The Access Server also generates a session token with a URL that contains the obSSO Cookie.
4. The session token and obSSOCookie are returned to the user’s browser.
5. The session token and obSSOCookie are sent to host2.domain2.com
6. The Web gate (webgate2) on host2.domain2.com sets the obSSOCookie for its own domain (.domain2.com) and satisfies the user’s original request for the resource host2.domain2.com/xyz.html. User gets the resource.
7. On the same browser if user accesses the host1.domain1.com page then resource will be presented without asking credentials as obSSOCookie is already available with .domain1.com (see step 3).

Q: What is an Access Server SDK?
A: The Access Manager Software Developer’s Kit (SDK) enables you to enhance the access management capabilities of the Access System. This SDK enables you to create a specialized AccessGate. The Access Manager SDK creates an environment for you to build a dynamic link library or a shared object to perform as an AccessGate. You also need the configureAccessGate.exe tool to verify that your client works correctly.

Q: What is an Identity XML? 
A: IdentityXML provides a programmatic interface for carrying out the actions that a user can perform when accessing a COREid application from a browser. For instance, a program can send an IdentityXML request to find members of a group defined in the Group Manager application, or to add a user to the User Manager.

IdentityXML enables you to process simple actions and multi-step workflows to change user, group, and organization object profiles.
After creating the IdentityXML request, you construct a SOAP wrapper to send the IdentityXML request to WebPass using HTTP. The IdentityXML API uses XML over SOAP. We pass IdentityXML parameters to the COREid Server using an HTTP request.This HTTP request contains a SOAP envelope.When WebPass receives the HTTP request, the SOAP envelope indicates that it is an IdentityXML request rather than the usual browser request.
The request is forwarded to the COREid Server, where the request is carried out and a response is returned. Alternatively, you can use WSDL to construct the SOAP request. The SOAP content looks like this, SOAP envelope (with oblix namespace defined), SOAP body (with authentication details), actual request (with application name and params). The application name can be userservcenter, groupservcenter or objservcenter (for organizations).

Q: What is an SSPI connector and its role in Oracle Access Manager integrations?
A:  The Security Provider for WebLogic SSPI (Security Provider) ensures that only appropriate users and groups can access Oracle Access Manager-protected WebLogic resources to perform specific operations. The Security Provider also enables you to configure single sign-on between Oracle Access Manager and WebLogic resources.
The WebLogic security framework provides Security Service Provider Interfaces (SSPIs) to protect J2EE applications. The Security Provider takes advantage of these SSPIs, enabling you to use Oracle Access Manager to protect WebLogic resources via:

• User authentication
• User authorization
• Role mapping

The Security Provider consists of several individual providers, each of which enables a specific Oracle Access Manager function for WebLogic users:
Authenticator: This security provider uses Oracle Access Manager authentication services to authenticate users who access WebLogic applications. Users are authenticated based on their credentials, such as user name and password.
The security provider also offers user and group management functions. It enables the creation and deletion of users and groups from the BEA WebLogic Server. It also provides single sign-on between WebGates and portals.
Identity Asserter: Like the Authenticator, this security provider uses Oracle Access Manager authentication services to validate already-authenticated Oracle Access Manager users using the ObSSOCookie and to create a WebLogic-authenticated session.
Authorizer: This security provider uses Oracle Access Manager authorization services to authorize users who are accessing a protected resource. The authorization is based on Oracle Access Manager policies.
Role Mapper: This security provider returns security roles for a user. These roles are defined in Oracle Access Manager, and they are provided by Oracle Access Manager using return actions on a special authentication policy. This authentication policy contains a resource with a URL prefix of /Authen/Roles. Role Mapper maps these roles to predefined security roles in WebLogic.

Q: Explain the integration and architecture of OAM-OAAM integration?
A: Using these products in combination will allow you fine control over the authentication process and full capabilities of pre-/post- authentication checking against Adaptive Risk Manager models.
The OAAM’s ASA-OAM integration involves two Oracle Access Manager AccessGates: one for fronting the Web server (a traditional WebGate) to Adaptive Strong Authenticator and one for the embedded AccessGate. The access server SDK to be installed and configureAccessGate tool to be run. The ASA bharosa files to updated with ASDK location. An application to be protected using ASA authentication scheme and to be tested for ASA landing page for login.

Here is how the flow goes:
1. User requests for a resource.
2. Webgate acting in the front end for ASA application will intercept the request and will redirect to the ASA application.
3. The user enter credentials and the Access SDK setup in the ASA application will contact the Access gate which inturn contacts the access server for validating the credentials.
4. Upon successful authentication, access server will generate obSSOCookie and will forwards it to the browser.
5. Then the user will be shown the requested resource.

Q: Explain IWA mechanism in Oracle Access manager?
A: The OAM has a feature which enables Microsoft Internet Explorer users to automatically authenticate to their Web applications using their desktop credentials. This is known as Windows Native Authentication.

1. user logs in to the desktop machine, and local authentication is completed using the Windows Domain Administrator authentication scheme.
2. The user opens an Internet Explorer (IE) browser and requests an Access System-protected Web resource.
3. The browser notes the local authentication and sends a token to the IIS Web server.
4. The IIS Web server uses the token to authenticate the user and set up the REMOTE_USER HTTP header variable that specifies the user name supplied by the client and authenticated by the server.
5. The WebGate installed on the IIS Web server uses the hidden feature of external authentication to get the REMOTE_USER header variable value and map it to a DN for the ObSSOCookie generation and authorization.
6. The WebGate creates an ObSSOCookie and sends it back to the browser.
7. The Access System authorization and other processes proceed as usual.
   The maximum session timeout period configured for the WebGate is applicable to the generated ObSSOCookie.

Q: Explain various major params defined in webgate instance profile?
A:

• Hostname: name of the machine hosting the access gate.
• Maximum User Session Time: Maximum amount of time in seconds that a user’s authentication session is valid, regardless of their activity. At the expiration of this session time, the user is re-challenged for authentication. This is a forced logout. Default = 3600. A value of 0 disables this timeout setting.
• Idle Session Time (seconds): Amount of time in seconds that a user’s authentication session remains valid without accessing any AccessGate protected resources.
• Maximum Connections: Maximum number of connections this AccessGate can establish. This parameter is based on how many Access Server connections are defined to each individual Access Server. This number may be greater than the number allocated at any given time.
• IPValidationException: IPValidationException is specific to WebGates. This is a list of IP addresses that are excluded from IP address validation. It is often used for excluding IP addresses that are set by proxies.
• Maximum Client Session Time  :Connection maintained to the Access Server by the AccessGate. If you are deploying a firewall (or another device) between the AccessGate and the Access Server, this value should be smaller than the timeout setting for the firewall.
• Failover Threshold: Number representing the point when this AccessGate opens connections to Secondary Access Servers. If you type 30 in this field, and the number of connections to primary Access Servers falls to 29, this AccessGate opens connections to secondary Access Servers.
•  Preferred HTTP Host : Defines how the host name appears in all HTTP requests as they attempt to access the protected Web server. The host name in the HTTP request is translated into the value entered into this field regardless of the way it was defined in a user’s HTTP request.
• Primary HTTP Cookie Domain: This parameter describes the Web server domain on which the AccessGate is deployed, for instance, .mycompany.com.

• IPValidation: IP address validation is specific to WebGates and is used to determine whether a client’s IP address is the same as the IP address stored in the ObSSOCookie generated for single sign-on.

Q: What is Policy Manager API?
A:  The Policy Manager API provides an interface which enables custom applications to access the authentication, authorization, and auditing services of the Access Server to create and modify Access System policy domains and their contents.

Q: When do you need an access gate?
A: An access gate is required instead of a standard webgate when you need to control access to a resource where OAM doesnot provide OOTB solution. These might include:

1. protection for non-http resources (EJB, JNDI etc.,)
2. Implementation of SSO to protect a combination of http and non-http resources.

A file called obAccessClient.xml is stored in the server where access gate is installed. this file contains config params entered through the configureAccessGate tool.

Q: Explain the flow when a user makes a request protected by an access gate (not webgate)?
A: The flow is shown below.

• The application or servlet containing the access gate code receives resource request from the user.
• The access gate code constructs ObResourceRequest structure and access gate contacts Access server to find whether resource is protected or not.
• The access server responds.
• If the resource is not protected, access gate allows user to access the resource. Otherwise..,
• Access Gate constructs ObAuthenticationScheme structure to ask Access Server what credentials the user needs to supply.
• The access server responds.
• The application uses a form or some other means to fetch the credentials.
• The AccessGate constructs ObUserSession structure which presents user details to Acc Server.
• If credentials are proven valid, access gate creates a session token for the user and then sends an authorization request to the access server.
• Access server validates if the user is authz to access that resource.
• Access gate allows user to access the requested resource.

Q: Explain how Form login works if the form login page is present in different domain from OAM?
A: The mechanism here is same as how the multi domain SSO works. Importantly, all of the activities for form authentication are carried out between the browser and one web server.
Now, suppose you want to access a resource http://www.B.com/pageB.html but still be authenticated by the login form on www.A.com.

• The authentication scheme required by pageB needs to have a redirect URL set to http://www.A.com.
• The WebGate at www.B.com redirects you to the NetPoint URL obrareq.cgi on www.A.com, with a query string that contains the original request (wu and wh).
• The WebGate on www.A.com will determine that you need to do a form login for that resource, so it will set the ObFormLoginCookie with the wu and wh values from the query string, but will set the ru field to /obrareq.cgi. WebGate on A then redirects your browser to the login form on A.
• When you post your credentials back to A, the ObFormLoginCookie is set back. WebGate on A authenticates your userid and password, sets the ObSSOCookie for the .A.com domain and redirects you back to the ru value from the ObFormLoginCookie, which is /obrareq.cgi.
• This time when your browser requests http://www.A.com/obrareq.cgi, it will pass the ObSSOCookie.
• WebGate will then redirect your browser back to the B webserver, http://www.B.com/obrar.cgi, with the cookie value and the original URL in the query string.
• The WebGate on www.B.com will extract the cookie value and set the ObSSOCookie for domain .B.com, and finally redirect you to http://www.B.com/pageB.html that you originally requested