OAM authentication with WebLogic server

This post provides the flow and steps for Oracle Access Manager (OAM) integration with Oracle WebLogic server - this is the integration of OAM with any protected application deployed on Web Logic server. This pattern is followed for all Oracle Fusion Middleware products (Oracle Identity Manager, Oracle SOA Suite, or Oracle Web Center etc) authentication with OAM. This is the core of how Single sign on works with Oracle Access Manager. The two important ingredients that make the sso happen are the OAM_REMOTE_USER Http Header and the OAMAuthen cookie. Http is the medium of transfer of data flow between all the components here - OAM, WebGate, WebLogic server, Application and lastly the user's browser. The user authentication information is carried in the Http Header. In essence, OAM authenticates a user to an application deployed on the WebLogic server using the Identity Asserter function. Below is the steps in this process (LINK to Oracle doc)   
(OAM single sign-on, authn policy, Credential collection)

 Here is a high level overview which shows User trying to access protected resource, other components are Access Manager Server and Admin server with their backend policy store. For detailed steps see further below.
OAM High Level Overview
Detailed steps
1) A user attempts to access an OAM protected Web application that is deployed on the Oracle WebLogic Server.

 2) WebGate on a reverse proxy Web server intercepts the request and queries the OAM Server to determine whether the requested resource is protected. (This reverse proxy server for example can be a OHS server with mod wls routing configuration). Additionally WebGate is also installed on the OHS server. This completes the step2 pre-requisites.

 3) If the requested resource is protected, WebGate challenges the user for credentials based on the type of OAM authentication scheme configured for the resource (Oracle recommends Form Login). The user presents credentials such as user name and password.
Identity Asserter Configuration with Oracle Access Manager and WebGates
(Note the dotted line from OAM Access Server on top right to AccessGate down below is a different flow and can be ignored in this discussion of the flow steps here.)

 4) WebGate forwards the authentication request to the OAM Server.

 5) OAM 11g Server validates user credentials against the primary user identity store and returns the response to WebGate (OAM 10g/11g Access Server validates user credentials against configured user directories). Upon:
Successful Authentication: Processing continues with Step 6.
Authentication Not Successful: The login form appears asking the user for credentials again; no error is reported.

 6) OAM Server generates the session token and sends it to the WebGate:
11g WebGate: Sets and returns the OAMAuthn cookie and triggers the OAM_REMOTE_USER (or OAM_IDENTITY_ASSERTER) token when policies are configured for this.
10g WebGate: Sets and returns OAM_REMOTE_USER or OAM_IDENTITY_ASSERTION headers in the request when policies are configured for this.


The Web server (OHS here) forwards this request to the proxy, which in turn forwards the request to the Oracle WebLogic Server using the mod_weblogic plug-in.
mod_weblogic forwards requests as directed by its configuration.
Note: mod_weblogic is the generic name of the WebLogic Server plug-in for Apache For Oracle HTTP Server 11g, the name of this plug-in is mod_wl_ohs. (in OHS server)

 7) WebLogic Server security service invokes the Oracle Access Manager Identity Asserter which is configured to accept tokens of type "OAM_REMOTE_USER" (or "OAM_IDENTITY_ASSERTER"). The Identity Asserter initializes a CallbackHandler with the header. In addition, the Identity Asserter sets up NameCallback with the username for downstream LoginModules.

 8) Oracle WebLogic Security service authorizes the user and allows access to the requested resource. (This resource is the Application which was deployed on WebLogic server).

 9) A response is sent back to the reverse proxy Web server.
10) A response is sent back to the browser

Comments

Post a Comment

Popular posts from this blog

VMware fix for Invalid manifest and ova file import failed errors

Image
Recently we got a OVA file for a virtual machine. The vendor instructions were to import the ova file in vmware Workstation, Player for Windows/Linux, Fusion for Mac, and VirtualBox as well.  The instructions were to take the available package and launch the VM with VMware workstation. The package contained  Module.mf, Module.ovf and Module-disk.vmdk and a Module.ova file. The .mf and .ovf file were 2 KB each whereas the vmdk was several gigs. The package also contained a Module.ova file which was several gigs as well. OVF           Open Virtualization Format MF             Manifest file VMDK       Virtual Machine Disk OVA           Open Virtualization Appliance The ovf file is a xml file that contains metadata for the ovf package The mf file contains the SHA1 hash codes of all files in the package The vmdk file is the disk image of the virtual machine,  VMware Workstation or VirtualBox. (vmdk format was originally developed by VMware and is an open format now). All of
Read more

SOAPUI - import certificate

Image
Note: SoapUI has two versions, one is open source and second Professional version. The open source can be download here . (confirmed link 12/19/2018). SSL Handshake issue:   There is an Issue in SoapUI version 5.3.0 (and 5.2.0 version) with SSL handshake error. It was resolved by updating below in vmoptions file ( refer here ). However, the error that shows up while trying to load wsdl is "Error loading WSDL" as below The fix is to Enable TLS 1.2 protocol for SOAP/REST calls in SoapUI, by ammending the vmoptions file to add the directive for TLS as (-Dsoapui.https.protocols=TLSv1.2). Refer here . Update: Version 5.5.0 does not have this issue. If you are on 5.3.0 better upgrade to 5.5.0 which is available now (Feb 2019). I had above issue as well as another issue reaching to https endpoint. Upgrade to 5.5.0 resolved issue. Select "Check for updates" under the Help menu and you will get option for upgrade. Select upgrade current version and accept all defaul
Read more

Centrally Managed Users (CMU) - New Feature in Oracle Database 18c

Image
Centrally Managed Users (CMU) Centrally Managed Users or CMU is a new feature introduced since Oracle DB 18c which allows simplified database user management through integration with Microsoft Active Directory (AD). Beginning with Oracle Database release 18c, version 18.1 and later supports direct integration with Microsoft Active Directory (AD) using the new centrally managed users capability. CMU allows the Oracle database to perform user authentication and authorization directly against AD. Benefits of CMU With centrally managed users, users accessing the database can be centrally managed to improve an organization's security posture. An enterprise user (a user in Microsoft Active Directory) can be exclusively mapped to a database account, or many enterprise users (in an Microsoft Active Directory group) can be mapped to a shared account in the database. Microsoft Active Directory groups can also be mapped to a database global role, which provides users with additional privilege
Read more