The flow is shown below:
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:
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.
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.
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.
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.
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).
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 = 36@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 trlated 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.
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.
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.
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.
ObSSOCookie and it is stateless.
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.
The following steps describes the flow when a user makes a request to access a resource protected by the Oracle Access Manager:
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.
Shared Secret key. It is configured in the Identity Admin console and can be generated by the OAM administrator.
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.
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.
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.
Following are the steps that explain how multi domain SSO works:
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:
The authentication scheme level which defines the level of the security defined for an application.
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:
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.