Smart Advice. Agile. Personalized. Transparent.

Adding external authorization for OPA Interviews

How to use external authentication for Oracle Policy Automation?

Oracle Policy Automation (OPA) Private Cloud Edition has supported external authentication since the February 2017 release. The documented Security integration is based on SAML2.0 and the example covered is integration with Oracle Access Manager (OAM). This setup enables SSO integration of your OPA instance, but requires  setup of OAM with Identity Federation and setup of OPA with SAML SSO. Additionally, if your OPA site is running in a WLS cluster a RDBMS based security realm needs to be set up during WLS domain creation. Although this is the recommended and comprehensive security configuration for production setups, users might seek a more lightweight integration to fulfill minimal requirements of external managed identities. As those minimal security requirements, we see typically the following:

»  Managing Identities externally (outside of OPA HUB) so that users can sign in with their well-known credentials following the external defined password policies

»  Assigning OPA Hub Permissions to externally managed identities within OPA-Hub

»  Protecting Web-Interviews to restrict access only to authenticated users belonging to a certain group

»  Passing user context to OPA Interview


This article aims to describe the solution setup for a more lightweight security integration for quick startup instances. A comparison of security capabilities between the documented setup and the lightweight setup is provided in the following table:


Setup (Covered below)

Documented setup

Using external managed Identities



User / Role assignment for OPA Hub Users



Protect Interviews based on external Users and Roles


(not documented for Private Cloud Edition)

Single Sign-On (SSO)






Table 1: Comparison of Security Integration Approaches


This article covers the implementation requirements and approach for the complete lightweight setup, which might be adopted in relevant usage scenarios. Optional marked steps might be skipped if not required.

All provided steps are for educational purposes. Code snippets are customizable without any support and maintenance of the author or Oracle. User may reuse and adopt them based on their own judgement and experience as part of their own implementation project.

As this article explains basic concepts only to a limited extend I encourage readers to familiarize with the OPA online documentation for the respective version in use to gain a deeper understanding.


The solution steps are tested using the following product versions:


» Oracle Policy Automation Private Cloud Edition, Release May 2017

» Oracle Weblogic Server

» Oracle IDM Suite

» Oracle JDeveloper

Security Integration Overview

In general, there is a separation of concern between Development, Integration, Deployment and Execution activities within OPA. The corresponding capabilities are modularized within OPA as depicted below

1: OPA Component overview

When enabling externally managed identities for OPA we have to distinguish the interactions by the different OPA components shown in Figure 1.

Enabling External Identities for Hub users

Hub users can be distinguished by the roles that are predefined in OPA, which are

  • Policy Author
  • Deploy Admin
  • Mobile User
  • Hub Administrator
  • Integration User

The online product documentation provides a comprehensive configuration to enable the external authentication. The Lightweight setup is basically a subset of necessary configuration steps as following:

To configure external authentication, follow these steps:

1.    Install OPA private cloud edition on a supported version of WebLogic

Note: For this step it is important to choose “Custom Roles and Policies” as Security Model during deployment time of OPA in Weblogic Server.

2.    The step “Configure your identity provider to support SAML authentication” can be skipped for Lightweight setup

3.    Configure an OPA site to use external authentication

1.     The step “Configure an external security provider for WebLogic” is executed differently for the lightweight setup than described in the standard documentation.
Instead of configuring a SAML 2.0 provider the lightweight setup can use either the Default Authentication Provider (using Weblogic’s embed LDAP as identity store) or a generic OID / LDAP Provider through Weblogic.

2.     The step “Protect the web application path with the Authentication provider” is skipped for the lightweight setup.

3.     The step “Restrict access to the OPA Hub authenticate path” is done as documented with relevant Group / Role Policy conditions.

4.    Enable external authentication mode for OPA Hub
This step is done as documented for lightweight setup. It might be a good idea to create an user in OPA Hub (beside the existing admin user) that is managed in external identity store AND has Hub administrator Role in OPA Hub to perform later manual role assignments.

5.    Assign external users to OPA Hub roles.
This step is done as documented for lightweight setup.

6.     Test your integration with Oracle Policy Modeling
This step is done as documented for lightweight setup.
Additionally you might want to test direct HUB access by requesting http://<server>:<port>/<deployment-name>/opa-hub which should result in a similar screen as shown in Figure 2.

2: Successful Test for external authentication in HUB

Enabling External Identities for Interview users

In order to restrict access to web based OPA Interviews on one hand and to provide the user context (e.g. user name) of the authenticated user to the OPA Interview on the other hand there is also a solution to this requirement. The solution is based on Oracle Access Manager and WebGates installed in the Web-Tier in front of the OPA Hub. This setup follows the recommendation to proxy all application tier requests by a WebTier (e.g. access restriction, load balancing, etc.). The building blocks of the solution are outlined in Figure 4.

4: OPA Application-Tier protected by Web-Tier with WebGate


OAM WebGate is typically a good choice to protect web resources with rule based policies in order to restrict access for external managed identities. For general concepts about OAM and WebGate and respective policy setup see the online documentation for those products.

The key to the solution described here is that we need a WebGate protection policy that protects your application Tier components and adds the user name (from external identitiy store) after successful authentication to the HTTP Header. For that you define an HTTP Header variable (e.g. HTTP_username) in the protection policy.

Now we need to make the OPA web interview aware of the HTTP Header variable and passing the value to an attribute within the OPA interview so that it can be consumed at any place in the interview where required.

For this step, there is currently no out of the box configuration capability. But with some simple steps the integration can be done very quickly.

In Figure 4 you can see the component “OPA-Mediator” in the Application Tier deployed side-by-side to OPA-Web (one OPA Hub component depicted in Figure 1). This OPA-Mediator is not part of the standard product nor does depend on internal knowledge of OPA. Therefore this component can be simply build, customized and deployed by users depending on their specific situations.

OPA-Mediator can be simply implemented as a standard JSP and deployed alongside with OPA in the application tier.

The following code examples are seen as a guideline how to build such kind of an OPA-Mediator for the purpose of passing external user context information to OPA Interviews.


<!DOCTYPE html>

<%@ page contentType="text/html; charset=utf-16" %>


   public String user_name = null; 

   public String request_url = null;

   public String target_url = null;

   public String redirect_url = null;




        <meta http-equiv="Content-Type" content="text/html; charset=utf-16"/>



            if (request.getHeader("HTTP_username") != null) {

                user_name = request.getHeader("HTTP_username");                         


            request_url = request.getRequestURI();           

            target_url = request.getParameter("target");                        

            if (user_name != null) {

                redirect_url = target_url +"?seedData={iv_benutzer:"+ user_name +"}";           


            if (target_url != null && redirect_url != null) {

                out.print("<meta http-equiv=\"refresh\" content=\"0; URL="+ redirect_url +" \"/>");






        if (target_url == null ) {

            out.println("ERROR: No valid Interview URL provided. Please contact the Administrator.");

        } else if (redirect_url == null) {

            out.println("ERROR: No valid Authentication. Please contact the Administrator.");

        } else {

            out.println("If you do not get redirected automatically please click <a href=\""+redirect_url+"\">here</a>");       





Now, after deploying the OPA-Mediator with Context root /OPA_Mediator and protecting the deployment by WebGate as well you can launch an Interview by


The sample request flow is finally as following

The browser (or any Application) requests the Web URL of an interview through the OPA_Mediator.
Example: http://web.server.domain/OPA_Mediator/LaunchInterview.jsp?target=http://web.server.domain/web-determinations/startsession/My_Interview

Web-Tier (OHS/Apache) redirects the request to application server (Weblogic) where OPA_Mediator is installed. This endpoint is protected through WebGate protection policy. Only users that are authenticated and belonging to a specific Role are allowed to access that endpoint, otherwise forbidden. In case the user is already authenticated and adhereing to the protection policy the request will be directed to OPA Interview immediately (step 5). Otherwise we continue with step 3.

User is not authenticated therefore the request is intercepted by WebGate

Redirect to OAM Login page for authentication

After Successful authentication OPA_Mediator is executed to extract HTTP Header variable, retrieve the target URL from the request and creates a redirect URL by appending the user as URL parameter to the target URL.

Finally OPA_Mediator executes a refresh with the new redirect URL.
This is turn requests the original Interview URL with the user name as URL parameter.

Note that the original Interview URL is also protected by a WebGate protection policy.


Steps to configure OAM WebGate

  1. Create Application Domain
  2. Protect dedicated OPA resources

  1. Configuration of Apache / OHS Web-Tier to forward requests to OPA

Einfügen in mod_wl_ohs.conf:

<IfModule mod_weblogic.c>

   <Location /opademo>

   SetHandler weblogic-handler

    WebLogicCluster wlsappserver1.server.domain:9001, wlsappserver2.server.domain:9001


   <Location /OPA_Mediator>

   SetHandler weblogic-handler

    WebLogicCluster wlsappserver1.server.domain:9001, wlsappserver2.server.domain:9001



Known limitations for this setup

Logging Out

Logging out from the Hub requires to destroy the browser session. There is currently no Logout-URL that could destroy the browser session. Therefore the safest way to log out is to close all browser windows.


Authorization issue in OPA with external identies when using case sensitivity in user names

After successful authentication against the external Identity store the username is passed to OPA. Since OPA Hub users and their role assignment have to be done within the OPA Hub as of now the user must exist within OPA Hub as well. OPA Hub forces the user name to be lower case. Even if you create a user “TOM”, OPA will create the user as “tom”.

When using external authentication, and providing user names with case sensitivity such as “Tom” or “TOM” in Basic Authentication screen, OPA will not match the user and their respective roles in OPA HUB. This results in a “Forbidden” screen as shown in Figure 3. The user gets (externally) authenticated, but OPA does not match the provided user credential to the internal OPA user.


3: Authorization Error (Forbidden)

An alternative for situations where the external identity store guarantees lowercase user names is, to set the Weblogic Security Provider option “Use Retrieved User Name As Principal” for the Authentication provider used for OPA. This would force to send the username in the format stored in the external identity store rather that passing the format typed during authentication.

Authorization issue when using admin.sh scripts to deploy

When lightweight external authentication is enabled as described above, the use of admin.sh script from command line fails to deploy artefacts with the error message shown below as HTTP 403 response.


ERROR (SOAPServiceRequestSender.java:292) - OPA-RN-4:Error while processing SOAP request:

















Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.