When accessing Fusion Applications (FA), a user typically requests their FA home page by typing in the URL in a browser window or clicking on a favorites link. The user then logs in to the application and gets to the home page and performs various activities such as - navigate to different parts of the application, perform transactions, view existing transactions, run or schedule jobs and view/create reports, among other things. For the end user, all it takes is clicking on links and typing appropriate values in fields most of the time. Behind the scene however, there are various components doing their part and interacting with each other to make all that happen. In this series of posts we will explain interactions between components and how the request flows between these components.
In this particular post, we will explain the authentication request flow within Fusion Applications which will demonstrate how various components talk to each other and at a high level also show the configuration which enables them to do the same.
Let us start with the components involved in Fusion Applications. Fusion Applications is built on the Fusion Middleware foundation, which consists of WebLogic Server, Identity Management Suite, HTTP Server and other middleware components such as SOA Suite, Business Intelligence etc. In the first part, we will not discuss all these components. Instead, we will focus on the components involved in the authentication. Following is a graphical depiction of these components:
Brief description of the components depicted above:
Web Browser: The primary purpose of a web browser is to bring information resources to the user, allowing them to view the information, and then access other information. This process begins when the user inputs a Uniform Resource Locator (URL), for example http://en.wikipedia.org/, into the browser.
The format of a URL is scheme://domain:port/path?query_string
The scheme, often referred to as protocol, defines how the resource will be obtained.
For Fusion Applications, all requests use HTTPS protocol for communication with the broswer.
The domain name gives the destination location for the URL
The port number is optional; if omitted, the default for the scheme is used. Default for HTTPS is 443
The path is used to specify the resource requested.
The query string contains data to be passed to software running on the server.
Load-Balancer (LBR): The LBR receives incoming HTTP(s) requests, terminates SSL (decrypts HTTPs) and redirects the request to one of the Web Hosts running Oracle HTTP Server. The Web Host to which the request is redirected depends on the algorithm used for load balancing - (e.g., round-robin) and whether persistence is enabled. If persistence is enabled, each subsequent request by the same client gets redirected to the same Web Host
Oracle HTTP Server: The HTTP Server receives incoming HTTP requests and redirects them to one of the WebLogic managed servers which serves that resource using mod_wl_ohs plugin. Each subsequent request by the same client is redirected to the same WLS managed server. There are 2 HTTP servers (optionally they can be clustered) in FA. One which acts as a front end for Fusion Applications (App OHS) and the other acts as a front end for Oracle Identity Management (Auth OHS)
Oracle WebGate: WebGate provides perimeter security. Intercepts any incoming request to OHS to check if the resource is protected, and if it is, whether the user is already authenticated and has access to it. Think of WebGate as a security guard outside a invitees only party. The job of the security guard is to validate that you are who you claim to be (checking your ID) and then letting you in. Before the guard lets you in, he puts a token on you (a band or a stamp) which is valid for a limited time. If you come out of the party and try to get in, if the token is still valid he lets you in without further checks. What you are allowed access to inside the party is none of its concern. Once the party is over, the token expires. If you try to come back the next day and show your existing token which has expired now, it will not let you in unless you authenticate yourself again at which point the guard will issue a new token. Similarly WebGate allows you entry by validating your credentials using Oracle Access Manager and on successful authentication, it sends a cookie back to the browser which is valid for a certain amount of time (configured in Oracle Access Manager). Once the authentication flow is complete it lets your request go to OHS which deals with providing you with the requested resource. On every subsequent request, WebGate only checks for a valid cookie. Only when the cookie expires, does it prompt you for reauthentication.
Oracle Access Manager (OAM): OAM holds an inventory of protected and public resources. If a user is not authenticated, then it challenges for credentials and validates against the user store. It provides an authentication token to WebGate once the user successfully authenticates. It also maintains a server side cookie - OAM_ID - which has details about user, timeout and identifier to coherence session.
Oracle Internet Directory (OID): OID is simply an LDAP directory which stores credentials.
Oracle Virtual Directory(OVD): OVD is a virtual layer which presents more than one directory as a single directory. Either Oracle Virtual Directory or Oracle Internet Directory is used by Oracle Access Manager to validate credentials passed by the user.
Oracle WebLogic Server: WebLogic is a JEE server which runs java applications. It completes the authentication flow by populating the principal (user and group) by using OAM Identity Asserter and downstream authentication providers (OVD or OID Authenticator) and provides the user with the requested resource.
A graphical depiction of the Authentication Request Flow:
Description of the Authentication Request Flow:
1. A user makes a request for the FA home page by typing in the URL, e.g., https://fusion.infusion.com/homePage/ fusion.infusion.com resolves to an IP address listened to by the LBR.
2. The LBR decrypts the request and redirects this request using HTTP protocol to port 10614 on one of the application web servers (CommonDomain's HTTP port for external traffic). WebGate then intercepts requests coming to OHS
3. Since this is the user's first request, there is no existing session. WebGate contacts OAM to check if the request is for a protected resource. "homePage" itself is not a protected resource so WebGate lets it pass through without authentication, but "homePage" redirects to a URL similar to homePage/adfAuthentication?_adf.authenticate=true&_afrLoop=719352011817477 which is a protected resource.
You can view the policies associated with these resources by logging in to the OAM Console and performing the following navigation:
Policy Configuration Tab -> Application Domains -> fs -> Double Click on Resources In the Search section of "fs Resources" tab on the right pane, choose Resource Type: HTTP and Type /homePage* in Resource URL field and click on search. OAM will display authentication and authorization policies associated with the resources which match the query string.
4. OAM queries the database and invokes the policy associated with this resource (Protected Resource Policy) and directs users to a login page - https://login.infusion.com/oam/server/obrareq.cgi?.......
login.infusion.com resolves to an IP address listened to by Load Balancer.
Note: A policy is associated with an Authentication scheme which governs the challenge method (Form in most cases), Authentication Module etc. A description of these topics is outside the scope of this article.
5. The LBR decrypts the request and redirects this request using HTTP protocol to port 7777 on one of the authentication web servers. As it is it's wont, WebGate intercepts requests coming to the OHS
6. WebGate contacts OAM to check if the request is for a protected resource. The resource URL /oam/.../* has a protection level of excluded which means WebGate doesn't contact OAM and allows the request to pass directly to OHS.
7. OHS looks up at the Virtual Host configuration, finds /oam location which instructs OHS to pass the request using weblogic-handler to OAM managed server. This configuration is stored in $OHS_INSTANCE_HOME/config/OHS/ohs<n>/moduleconf/sso_vh.conf file. Here is a relevant excerpt from the file. Pay special attention to the highlighted items:
Once it receives the response back from WLS, it sends the response back to the LBR
8. The LBR encrypts the response (remember the scheme is https) and sends the login page back to the end user
9. The user types in their credentials and submit the page. A post request is sent back to the server with the entered credentials
POST /oam/server/auth_cred_submit HTTP/1.1
This request also goes via the LBR, through the OHS to the OAM managed server (wls_oam1). In the interest of keeping the diagram simple, we are not depicting this flow in the picture above.
10. Once OAM receives the credentials, it validates it against the User store configured for the Authentication module being used. Depending on how you have configured your system, it could be OVD or OID. For the purpose of this post, we've configured OVD as the user store. OVD in turn uses the adapter to validate the credentials against the underlying directory - OID. If the credential validation is successful, OAM sends access token back to WebGate
11. WebGate checks the access token and sets the OAMAuthnCookie and triggers the OAM_REMOTE_USER token and passes the request to OHS.
12. OHS looks up the virtual host configuration, finds /homePage location which instructs OHS to pass the request using weblogic-handler to HomePageServer_<n> managed server. This configuration is stored in $OHS_INSTANCE_HOME/config/OHS/ohs<n>/moduleconf/FusionVirtualHost_fs.conf file. Here is a relevant excerpt from the file. Pay special attention to the highlighted items:
13. WebLogic's security framework invokes OAMIdentityAsserter which asserts user identity. The downstream authentication provider (OVDAuthenticator in our case) populates the subject with principals (user and group)
Note: The Home page is constructed with content from various WLS domains (depending on how you have customized your home page). Each of the WLS domains which serves the content, performs this step. In the interest of keeping the explanation simple, this has not been depicted in the diagram.
14. The HomePageServer constructs the home page and sends the response back to OHS which in turn sends the response back to the LBR. The LBR encrypts the response and sends it back to the browser which renders the home page!