Open ESB Tip : Securing WLM Application With Open SSO

As the final part of my WLM SE Trail I will be securing the previously built Visual Web Pack Application using OpenSSO and the previously configured OpenDS instance. The choice of Visual Web Pack is arbitrary and you could do the same with the ICEfaces implementation.

I will be simulating a multiple box deployment strategy for two reasons:
  1. This is more likely to be a production type implementation.
  2. It actually make configuration of OpenSSO easier.
This implementation will take you through the graphical implementation but you do have the option to configure OpenSSO using a number of scripts and XML files but these will not be discussed in this blog entry.

WLM SE Trail
  1. Configuring WLM SE to use Open DS.
  2. Implementing a Vendor Relationship Management Portal (Part 3) (VRMP Build Video).
  3. Developing the Worklist Interface using Visual Web Pack.
  4. Developing the Worklist Interface with ICEfaces.
  5. Adding Security Using OpenSSO.


OpenSSO Installation and Configuration


Before we install and configure OpenSSO we will need to create a second domain within you GlassFish instance and then modify your hosts file to add two additional fully qualified names that we refer to the localhost address,, which will be used during the configuration and implementation of OpenSSO and the proxy running on the GlassFish server.

Edit your host file and add the following entries:
Once you have done this we need to create the additional OpenSSO Domain under you existing GlassFish instance. The modified setup.xml I used can be downloaded here and this will build a domain based on the following properties:

<property name="" value="domainAM"/>
<property name="" value="server"/>
<property name="admin.user" value="admin"/>
<property name="admin.password" value="adminadmin"/>
<property name="admin.port" value="21048"/>

<property name="instance.port" value="21080"/>
<property name="orb.port" value="21037"/>
<property name="imq.port" value="21076"/>
<property name="https.port" value="21081"/>
<property name="jmx.port" value="21086"/>
<property name="orb.ssl.port" value="21038"/>
<property name="orb.multi.port" value="21039"/>

In addition we will need to update the existing WLM LDAP Structure to add a number of additional attributes to the existing users. To do this you will need to import the following OpenSSO
  • am_remote_opends_schema.ldif
  • fam_sds_schema.ldif
  • Modified wlmOpenSSO.ldif.

Installation  Steps

Installing  OpenSSO

I will assume that you have used the attached setup xml above to create the OpenSSO Manager domain and hence all port numbers referred to in this entry will be based on those in the xml. In addition I will assume that we are using the WLM OpenDS installation previously defined for the authentication data store.

Add OpenSSO Policy information

Edit the <GlassFish Install Dir>/domains/domainAM/config/server.policy file and add the following:

grant {
permission "\*", "listen,connect,accept,resolve";
permission java.util.PropertyPermission "\*", "read, write";
permission java.lang.RuntimePermission "modifyThreadGroup";
permission java.lang.RuntimePermission "setFactory";
permission java.lang.RuntimePermission "accessClassInPackage.\*";
permission java.util.logging.LoggingPermission "control";
permission java.lang.RuntimePermission "shutdownHooks";
permission "getLoginConfiguration";
permission "setLoginConfiguration";
permission "modifyPrincipals";
permission "createLoginContext.\*";
permission "<<ALL FILES>>", "read,write,execute,delete";
permission java.util.PropertyPermission "java.util.logging.config.class", "write";
permission "removeProvider.SUN";
permission "insertProvider.SUN";
permission "doAs";
permission java.util.PropertyPermission "", "write";
permission java.util.PropertyPermission "", "write";
permission java.util.PropertyPermission "", "write";
permission java.util.PropertyPermission "user.language", "write";
permission "\*", "accept";
permission "setHostnameVerifier";
permission "putProviderProperty.IAIK";
permission "removeProvider.IAIK";
permission "insertProvider.IAIK";
permission java.lang.RuntimePermission "setDefaultUncaughtExceptionHandler";
permission "newMBeanServer";
permission "\*", "registerMBean";
permission java.lang.RuntimePermission "createClassLoader";
permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
permission "getSubject";
permission "register";
permission "monitor";
permission "createMBeanServer";
permission java.util.PropertyPermission "javax.xml.soap.MetaFactory", "write";
permission java.util.PropertyPermission "javax.xml.soap.MessageFactory", "write";
permission java.util.PropertyPermission "javax.xml.soap.SOAPConnectionFactory", "write";
permission java.util.PropertyPermission "javax.xml.soap.SOAPFactory", "write";
permission "getProxySelector";
permission "getProperty.authconfigprovider.factory";
permission "setProperty.authconfigprovider.factory";
permission "doAsPrivileged";
permission "modifyPublicCredentials";
permission "insertProvider.XMLDSig";
permission "putProviderProperty.WSS_TRANSFORM";
permission "insertProvider.WSS_TRANSFORM";
permission "getProperty.ocsp.\*";

Deploying the OpenSSO war and basic Configuration

We will need to install the opensso.war file and navigate to its URL to configure the OpenSSO instance. To do this we will need to start the domainAM previously defined and the navigate to the admin console ( and add a new Web Application. Before we do this add / modify the following JVM options for the domainAM.
  • -Xmx1024m

Once this has been done you will need to configure the OpenSSO Instance by launching the opensso application. You will then be presented with an Configuration Option Screen at which you should select "Create New Configuration".

This will now take you through the configuration of your OpenSSO instance as Follows:

Step 1 : General

Here we set the password for the default amAdmin user:
  • password : adminadmin

Step 2: Server Settings
This page defines the configuration of the OpenSSO server. If you have used a fully qualified name in your url it will pick the final part as the Cookie Domain:
  • Server URL :
  • Cookie Domain :
  • Platform Locale : en_US
  • Configuration Directory : C:\\Software\\opensso\\config\\gf21048

Step 3 : Configuration Store
Here we are able to specify where OpenSSO will create and maintain its configuration information. I will assume that this is the first instance of OpenSSO we are configuring on the box and hence we will select First Instance and select OpenSSO as the configuration Datastore. This will install an OpenDS instance below the configuration directory.
  • SSL Enabled : False
  • Host Name :
  • Port : 50389
  • Encryption Key : Use what is generated
  • Root Suffix : dc=opensso,dc=java,dc=net
  • Login Id : cn=Directory Manager
  • Password : adminadmin

Step 4 : User Data Store
For simplicity we will create the User Data Store using the same OpenDS instance created in the previous step. This is done because we will later create a specific Data Store relating to the WLM User Data.

Step 4 : User Data Store Settings (Alternative)
This screen allows you to specify the location of the User Authorisation data and we will use the OpenDS structure we have created previously for the WLM SE.
  • SSL Enable : False
  • Directory Name :
  • Port : 2389
  • Root Suffix : ou=People,dc=wlm,dc=openesb,dc=com
  • Login Id : cn=Directory Manager
  • Password : adminadmin
  • User Data Store Type : Generic LDAP

Step 5 : Site Configuration
We will not be running the instance behind a Load Balancer so we will select No here.

Step 6 : Default Policy Agent
This screen allows us to define the password for the default policy agent; we can add additional agents later.
  • Password : agentadmin

Finally the summary of what we have specified is displayed and we can now create the configuration.

Selecting the "Create Configuration" will execute the appropriate OpenSSO scripts and on completion display the message below.

Configuring OpenSSO For WLM Web Applications 

Now that we have created the default configuration we will need to extend it to specify the Authentication / Authorisation requirements for the WLM Web Application. To do this we will not use the default, top-level, Realm configuration but rather create our own.

Login to OpenSSO, if you have close the login in window displayed following completion of the basic configuration navigate to, using amAdmin / adminadmin.

Logging in will display will display the "Common Tasks" Tab by default.

Step 1 : Define Identity Repository
Select the "Access Control" Tab and then the Root Realm (Top Level) and this will navigate to the Realms Property page and select "Data Store" Tab which should display a single Data Store "generic ldapv3" (created during the initial configuration). If this does not appear then you will need to create you own Generic Data LDAP Data Store.
Following the creation of this data selecting the Subjects Tab should display the following:

Step 2 : Create New Sub-Realm
Select the "Access Control" Tab and select the New Realm Button.
  • Name : (match our OpenDS Structure but only for consistency)
  • Parent : /
  • Leave the rest of the options as default.

Save the new Realm and this will return you to the "Access Control" Tab displaying the new Realm.

Repeat the the process and create the Realm wlmVWP below the Realm.

Once the wlmVWP Realm has been created select it from the Realm List and add the following Realm Alias:

Step 3 : Create Top (Root) Level Referral Policies
Select the Top Level (Root) Realm / and on the Properties Page select the Policies Tab and Select New Referral. This will create a new Referral that we will name " Web Application Referral".

Saving the new Referral will return to the Policies Tab. We can now select the new Referral and add the appropriate Referral Rules.

Select New Rule and create a "URL Policy Agent" Rule.

For the new rule specify the following:
  • Name : Web Application
  • Resource Name :\*

Select New Referral and create the following:
  • Name : Sub Realm Referral
  • Filter : \*
  • Value : (Your Sub Realm)

When the Edit Policy Screen is displayed the Save button must be pressed to save the new Referrals and Policy data.

Return to the "Access Control" page and select the Realm then repeat the steps above.

Step 4 : Create Sub Realm Authentication Policies
Now that we have created the Referral policies at the root level we can create the appropriate Sub Realm Policies. These can not be created prior to the creation of the Referral policies. Navigate to the Policies Tab for the wlmVWP Sub Realm and create New Policy:
  • Name : wlmVWP Web Application
The a new Rules With the following information.

  • Name : wlmVWP Web Application
  • Resource Name :\*
  • GET : True
  • POST : True

Having created the Authentication Policies we will need to add some Subjects and Conditions. Select New Subject and create the following :
  • Type : Authenticated Users
  • Name : Authenticated WLM Users

Create a New Condition with the following information:
  • Type : Authentication To Realm
  • Name : WLM SE LDAP Realm
  • Filter : \*
  • Realm : /

In the release of OpenSSO used at the time of publication of this entry their is a feature in the authentication process that causes the Login page to be display twice when using "Authentication to a Realm". It forces you to authenticate with the Top Level Realm and then the Sub Realm. As a temporary solution you can set the Realm to authenticate to as the Top level Realm.

Step 5 : Create Policy Agent
We now need to create the OpenSSO Agent information which will be used by the remote GlassFish Instance to connect. We will do this within the top level Realm as follows:
  1. Select the wlmVWP Realm.
  2. Select The Agents Tab.
  3. Select The J2EE Sub Tab.
  4. Create New Agent
    • Name : WLMVWPJ2EEAgent
    • Password : adminadmin
    • Configuration : Centralized
    • Server URL :
    • Agent URL :
  5. Save

If you are seeing the double Login prompt and still require Authentication at the wlmvwp Realm then we can modify the J2EE Agent to use the Gateway Servlet instead of the default method. This is documented in the User Documentation at "Resourced-Based Authentication" but essentiall consists of the following modification the the J2EE Agent.
  1. Select the WLMVWPJ2EEAgent
  2. Switch to the OpenSSO Services Tab
  3. Add the OpenSSO Login URL
  4. Move the URL to the top position

This change should not be required in the later releases.

We have now completed the OpenSSO Domain configuration.

Installing  OpenSSO GlassFish Agent

Extract And Configure

Download the GlassFish OpenSSO Agent ( and extract into appropriate directory. Within the bin directory execute the agentadmin --install command.

Application Server Config Directory
URL where OpenSSO is running
Agent URL
Agent Profile Name
Agent Password file
C:\\Software\\opensso\\agents\\gf4848\\wlmVWP\\WLMVWPJ2EEAgent.password. This should be created as a simple text file with a single line containing the password in plain text.

Once installed we will need to edit the following :

  • <Agent Base Dir>/Agent_001/config/ and modify / add the following:

    com.sun.identity.agents.config.filter.mode = URL_POLICY

    com.sun.identity.agents.config.login.url[0] =

    com.sun.identity.agents.config.logout.uri[WLMPOWebApplication] =
    com.sun.identity.agents.config.logout.request.param[WLMPOWebApplication] = Logout

  • <Agent Base Dir>/Agent_001/config/ and modify / add the following : = /

The Application Server should now be restarted.

Install Agent War

Navigate to the GlassFish servers admin Console ( and install the agentapp.war file that can be located in the <Agent Base Dir>/etc directory.

Modifying the Visual Web Application

OpenSSO jars

Before we can access the OpenSSO classes we will need to add the following jar files to the VWP Application:
  • agent.jar
  • openssoclientsdk.jar
These can be found in the agents lib directory.

Editing the Web.xml

Before the Web Application can be used with OpenSSO we need to modify the web.xml to add an additional filter that will cause it to execute the OpenSSO policies. Edit the file and add the following:

<filter-class> com.sun.identity.agents.filter.AmAgentFilter </filter-class>

Modifing SessionBean getUsername method

Because we will be removing our original Logon Screen from the process control we will need to retrieve the Username (Principal) information from the Authenticated OpenSSO Session. To do this we will need to modify the getUsername() method in the the SessionBean as follows:

public String getUsername() {
try {
if (username == null) {
SSOToken token = getAmSSOToken();
if (token != null) {
String principalDN = token.getPrincipal().getName();
int nameEndPos = principalDN.indexOf(",");
if (nameEndPos > 3) {
username = principalDN.substring(3, nameEndPos);

} catch (SSOException sSOException) {
return username;
In addition to this we will need to add a number of methods to retrieve the information from the OpenSSO Session as follows:

\* OpenSSO Methods
private SSOTokenManager amSSOTokenManager = null;

public SSOTokenManager getAmSSOTokenManager() {
log("\*\*\* APH : getAmSSOTokenManager() : START");

if (amSSOTokenManager == null) {
try {
amSSOTokenManager = SSOTokenManager.getInstance();
} catch (SSOException ex) {
Logger.getLogger(SessionBean1.class.getName()).log(Level.SEVERE, null, ex);

log("\*\*\* APH : getAmSSOTokenManager() : END");

return amSSOTokenManager;
private SSOToken amSSOToken = null;

public SSOToken getAmSSOToken() {
log("\*\*\* APH : getAmSSOToken() : START");

HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
SSOTokenManager manager = getAmSSOTokenManager();
if (amSSOToken == null && manager != null) {
try {
amSSOToken = manager.createSSOToken(request);
log("\*\*\* APH : getAmSSOToken() : isValid " + amSSOTokenManager.isValidToken(amSSOToken));
log("\*\*\* APH-I2 : Principal " + amSSOToken.getPrincipal());
log("\*\*\* APH-I2 : IP Address " + amSSOToken.getIPAddress().getHostAddress());
log("\*\*\* APH-I2 : Hostname " + amSSOToken.getHostName());
} catch (SSOException ex) {
Logger.getLogger(SessionBean1.class.getName()).log(Level.SEVERE, null, ex);
} else {
log("\*\*\* APH : Failed to get Token Manager " + manager);

log("\*\*\* APH : getAmSSOToken() : END");

return amSSOToken;
private AMIdentityRepository amIdentityRepository = null;

public AMIdentityRepository getAmIdentityRepository() {

SSOToken token = getAmSSOToken();
if (amIdentityRepository == null && token != null && amSSOTokenManager.isValidToken(token)) {
try {

amIdentityRepository = new AMIdentityRepository(token, token.getPrincipal().getName());
} catch (IdRepoException ex) {
Logger.getLogger(SessionBean1.class.getName()).log(Level.SEVERE, null, ex);
} catch (SSOException ex) {
Logger.getLogger(SessionBean1.class.getName()).log(Level.SEVERE, null, ex);
return amIdentityRepository;
private AMIdentity amIdentity = null;

public AMIdentity getAmIdentity() {

AMIdentityRepository repository = getAmIdentityRepository();
if (amIdentity == null && repository != null) {
try {
amIdentity = repository.getRealmIdentity();
log("\*\*\* APH-I3 : Attributes " + amIdentity.getAttributes());
} catch (IdRepoException ex) {
Logger.getLogger(SessionBean1.class.getName()).log(Level.SEVERE, null, ex);
} catch (SSOException ex) {
Logger.getLogger(SessionBean1.class.getName()).log(Level.SEVERE, null, ex);
return amIdentity;

Change Start Page

Finally we will need to modify the starting page within the application. Right click on the TaskListPage and select "Set As Start Page".

Post a Comment:
Comments are closed for this entry.

As a member of the Oracle A-Team we specialise in enabling and supporting the Oracle Fusion Middleware communities.


« August 2016