Here I have explained steps we follow to protect a web application through Oracle Access Manager (OAM) server. I have considered form-based login for this where login page is hosted at application end. Have also considered that OAM server, OID server (user store) and OHS instance are already installed and are up and running.
- First thing first- application team to provide information to Identity and Access Management (IAM) team:
- URLs of all the application resources that are to be protected through OAM.
- Details of protected and unprotected resources means resources which require user's authentication and resources which are to be kept public or unprotected in OAM.
- Host and port where application is running
- In case OAM and application servers are running on separate machines, then /etc/hosts file of OAM server needs to have host & IP entry of application server and vice versa. This is to allow the network traffic between both servers.
- Application team to apply the logic of login button. Logic is of submitting the credentials through POST request to credential collector URL (/oam/server/auth_cred_submit).
- Now login to OAM console and create a new SSO Agent. SSO agent is a host identity which is required to create connectivity between OHS and OAM server. While creating SSO Agent we need to provide Logout URL and select 'Allow Credential Collector Operations'. By checking this option we are allowing OHS agent to intercept user credentials during the login process. This way we are making authentication process a bit more secure by adding up a layer of web server during the process. Without this option, credentials will be directly intercepted by OAM server.
- After saving SSO agent, click on Download button to download the wallet files of SSO Agent. These files will be copied in OHS agent under this path (please note that path varies as per the installation): /web server/Oracle/Middleware/Oracle_WT1/instances/instance1/config/OHS/ohs1/webgate/config
- Now we need to configure application's host, port and context root in OHS. To do this, open mod_wl_ohs.conf file placed under the directory - /web server/Oracle/Middleware/Oracle_WT1/instances/instance1/config/OHS/ohs1 This is for OHS to understand that web resource which user is trying to access is protected by OAM. OHS already have got wallet files which it will use to connect to OAM server.
- Restart OHS agent using opmnctl.sh script under the path (path varies as per installation)- /web server/Oracle/Middleware/Oracle_WT1/instances/instance1/bin
- Now login to OAM console and configure User Identity Store. This is required by OAM to authenticate users against the configured user store during login request.
- Create new Authentication Module and select identity store created in step 7.
- Create Authentication Scheme. Through authentication scheme, we configure the challenge mechanism required to authenticate users. Authentication scheme has parameters to be configured:
- Challenge method (Form, X509, WNA etc)
- Challenge Redirect URL. This contains the hostname and port of OHS (http://HOSTNAME:PORT)
- Authentication Module. Select the Authentication Module created in step 5
- Challenge URL. This contains the web path of login page where we want user to redirect for entering login credentials
- Create Application Domain. First, we need to create authentication and authorization policies.
- Create a new Authentication Policy and select Authentication scheme created in step 5
- Create new Authorization Policy. Here we need to configure OID groups for group-based authorization. Also in Response tab, we can configure OID attributes to be sent through HTTP header traces, which can be further utilized by the application.
- Now in resource tab, we need to start adding application resources to be protected through OAM. While adding resources in application domain we need to select the authentication and authorization policies created.
Figure 1 is a high-level view which shows various OAM components used while authenticating a user against user store (OID/OUD) and providing access to the user for a web resource.
Figure 1: Authentication flow of a web application protected by OAM server
Let me explain the authentication flow while a user tries to access OAM protected resource which is pictured in Figure 1.
User tries to access an OAM protected web resource. Since the resource is protected by OAM, OHS will intercept the request. OHS will check mod_wl_ohs.conf file and since there is an entry of this application’s context root, it will hit OAM server’s application domain through SSO agent. After OAM server finds the entry of resource which user is trying to access, it will execute authentication policy tied to that resource. Authentication policy will execute the authentication scheme configured. Authentication scheme will find the challenge URL and will ask OHS to redirect the user to that login URL. OHS will now respond to the browser with the login URL. The browser will then try to redirect the user to this login URL. Again OHS will intercept this request and in a similar fashion, it invokes OAM server. OAM server will check its application domain and will find out the entry of login page in its application domain. Since the login page is configured as public or unprotected, it will respond OHS as a success. OHS will then request application server for the HTTP content of login page. The application server will respond back with the HTTP content, which OHS will forward to the browser. The browser will display the login page to the user.
Now the user will enter her credentials (userId and password) and will submit the page. This submission will send a POST request to OAM’s credential collector URL along with user’s ID and password, which she has entered in the login form. This configuration is mentioned in step 3 as well. OHS will intercept this request and will invoke OAM server. OAM server will send the credentials to the configured identity store (OUD/OID or any other user store). Identity store will validate the credentials and will reply back to OAM server with a success or failure. If success, OAM server will execute authorization policy. If there is any group based authorization configured, OAM server will send the request to the user store to check if the user is having access to the particular group. If yes, user store will reply back with a success to OAM server.
After receiving success from user store, OAM server will create the session for the user and will reply back to OHS with a success and user’s session information. OHS will then request the application server for the HTTP content of the resource which user was trying to access. The application server will reply back with the HTTP content. OHS will receive the HTTP contents and will send the same to the browser along with user’s session information. The browser will store user’s session info into cookies and will redirect the user to the resource. This way user will have secure access to the resource after authentication.
Authored By - Pankaj Kashyap
TCS Cyber Security Practice