Identity and Cloud Security A-Team at Oracle Open World

I just wanted to let everyone know that Kiran and I will be presenting with our good friend John Griffith from Regions Bank at Oracle Open World next week. Our session is Oracle Identity Management Production Readiness: Handling the Last Mile in Your Deployment [CON6972] It will take place on Wednesday, Sep 21, 1:30 p.m. […]

Configuring Oracle Public Cloud to Federate with Microsoft Azure Active Directory

Introduction Companies usually have some Identity and Access Management solution deployed on premises to manage users and roles to secure access to their corporate applications. As business move to the cloud, companies will, most likely, want to leverage the investment already made into such IAM solutions and integrate them with the new SaaS or PaaS applications that […]

Avoiding LibOVD Connection Leaks When Using OPSS User and Role API

The OPSS User and Role API ( provides an application with access to identity data (users and roles), without the application having to know anything about the underlying identity store (such as LDAP connection details). For new development, we no longer recommend the use of the OPSS User and Role API – use the Identity […]

Improve SSL Support for Your WebLogic Domains

Introduction Every WebLogic Server installation comes with SSL support. But for some reason many installations get this interesting error message at startup: Ignoring the trusted CA certificate “CN=Entrust Root Certification Authority – G2,OU=(c) 2009 Entrust, Inc. – for authorized use only,OU=See,O=Entrust, Inc.,C=US”. The loading of the trusted certificate list raised a certificate parsing exception […]

Where has your LDAP connection pool gone?

Introduction You have deployed Oracle BPM and decided to run some load tests against it. You’re concerned, among other things, about the behavior of your backend LDAP server under peak times, whether it’s going to be able to handle the load or not. You check the security providers settings in Weblogic Server and see you […]

Converting SSL certificate generated by a 3rd party to an Oracle Wallet

     Recently a customer asked me how to import his private key and certificate into an Oracle HTTP Server Wallet.
The customer generated a CSR outside the OHS Wallet Manager, using Open SSL, and sent it to a CA to get his certificates issued by them.
Unfortunately, the Wallet Manager only allows you to import certificates which were created for a CSR generated by the Wallet itself.
Despite this minor limitation, there is a workaround to get your private key, certificate and CA trusted certificates chain into Oracle Wallet.
This post explains the simple steps to achieve this, with a little help from Open SSL.

  1.       What you will need:
a. openssl installed in a machine
b. The server’s certificate (PEM format)
c. The server’s encrypted private key and it’s password
d. The CA root and intermediate certificates (these must be concatenated into a single file, also in PEM format)
        2.    On a server with openssl installed, issue the following command:

openssl pkcs12 -export -in certfile -inkey keyfile -certfile cacertfile -out ewallet.p12



                certfile: is the server’s certificate
                keyfile: is the server’s private key
                cacertfile: is the CA’s concatenated root and intermediate certificates.
Note that the resulting file must be named ewallet.p12 in order to be recognized by Oracle Wallet Manager.


3      3.       Enter the private key’s passphrase when prompted for it.
        4.       Enter an export password when prompted for it. You MUST supply a non-blank password. You will need to type it again as verification.
        5.       Upload the ewallet.p12 file to the Oracle Application Server. Move it to where the OHS can access it.
        6.       Start the Oracle Wallet Manager application.
        7.      Under the Wallet menu, click Open.
        8.      You will likely receive an error message about the default wallet directory not existing, and asking you if you want to continue. Click Yes.
       9.   You will be asked to select the directory where the wallet file is located. Find the directory where you moved the file ewallet.p12 to.
      10.   You will be asked for the wallet password. Enter the export password you entered when converting the certificate.
      11.   The wallet should open, and the certificate may be displayed as empty – don’t worry about that right now. You should also see the CA certificate under “Trusted Certificates”.
      12.   Under the Wallet menu, select “Auto Login”. Verify that it was selected by viewing the Wallet menu again; the Auto Login box should now have a check mark.
       13.  Under the Wallet menu, select “Exit” to quit the Oracle Wallet Manager application.
       14.   Now you should have 2 files in the directory: ewallet.p12 and cwallet.sso. Both files must be together at the same directory so the OHS can access the wallet.
       15.   Shutdown OHS.
       16.   Modify your OSH ssl.conf (default location should look something like /home/oracle/Middleware/Oracle_WT1/instances/instance1/config/OHS/ohs1/ssl.conf) so the directive SSLWallet points to the directory where you saved both files, for example:
      SSLWallet “${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/keystores/default

 17.   Start OHS and access its HTTPS home page. Inspect the certificate presented by the browser and you should see your new certificate and the CA chain.



Attaching OWSM policies to JRF-based web services clients

I’ve recently came across a question in one of our internal mailing lists where a person was under the impression that he would have to write code to propagate the identity when making a web service call using OWSM policies. My answer was something like: “depending on the type of your client you may have to write some very small piece of code to attach a policy, but you should not write code at all to either retrieve the executing client identity or to do the propagation itself”. Fortunately, I had an unpublished article that applied 100% to his use case. And here it is now (a little bit revamped).

OWSM (Oracle Web Services Manager) is Oracle’s recommended method for securing SOAP web services. It provides agents that encapsulate the necessary logic to interact with the underlying software stack   on both service and client sides. Such agents have their behavior driven by policies. OWSM ships with a bunch of policies that are adequate to most common real world scenarios.

Applying policies to services and clients is usually a straightforward task and can be accomplished in different ways. This is well described in the OWSM Administrators Guide. Looking from the client perspective, the docs describe how to attach policies to SOA references, connection-based clients (typically ADF-based clients) and standard Java EE-based clients using either Enterprise Manager or wlst.

Oracle FMW components (like OWSM agents) are typically deployed on top of a thin software layer called JRF (Java Required Files), providing for the required interoperability with software stacks from different vendors.

This post is a step-by step showing how to code a JRF-based client and attach OWSM policies to it at development-time using Oracle JDeveloper.

This is a 3-step process:

a) Create proxy-supporting classes;
b) Use the right client programming model;
c) Attach OWSM policy to the client;

1. Creating proxy-supporting classes

Very straightforward.
Select a project and go to File -> New and select Web Services in the Business Tier category. On the right side, choose Web Service Proxy and follow the wizard.


2. Picking the right client programming model

For clients on 11g R1 PS2 and later, use oracle.webservices.WsMetaFactory. If your client is going to run on 11g R1 or 11g R1 PS1, use the deprecated All these classes are available in jrf-client.jar file, located at oracle_common/modules/oracle.jrf_11.1.1 folder in your middleware home installation.

2.1 Code sample using (up to 11g PS1)

import javax.xml.namespace.QName;
import javax.xml.parsers.DocumentBuilderFactory;
import oracle.webservices.ClientConstants;
import org.w3c.dom.Element;
String endpoint = "";
URL wsdlURL = new URL(endpoint+"?WSDL");
ServiceDelegateImpl serviceDelegate = new ServiceDelegateImpl(wsdlURL, new QName("", "MyAppModuleService"), oracle.webservices.OracleService.class);
MyAppModuleService port = serviceDelegate.getPort(new QName("", "MyAppModuleServiceSoapHttpPort"), MyAppModuleService.class );

InputStream isClientPolicy = <Your_Client_Class_Name>.class.getResourceAsStream("client-policy.xml");
Map<String,Object> requestContext = ((BindingProvider) port).getRequestContext();
requestContext.put(ClientConstants.CLIENT_CONFIG, fileToElement(isClientPolicy));
requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpoint);

// Add other properties here. For identity switching add
// requestContext.put(SecurityConstants.ClientConstants.WSS_CSF_KEY, "<AppID_csf_key>");

// Utility method to convert an InputStream into an org.w3c.dom.Element
public static Element fileToElement(InputStream f) throws IOException, Exception {
DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
return builderFactory.newDocumentBuilder().parse(f).getDocumentElement();

In this sample, MyAppModuleService is the port interface generated by JDeveloper in the step before.

The parameters to the QName object constructor are the target namespace and the service/port name, both found in the web service wsdl.

2.2 Code sample using oracle.webservices.WsMetaFactory (11g PS2 +)

import java.util.Map;
import javax.xml.namespace.QName;
import javax.xml.parsers.DocumentBuilderFactory;
import oracle.webservices.ClientConstants;
import oracle.webservices.ImplType;
import oracle.webservices.WsMetaFactory;
import org.w3c.dom.Element;

String endpoint = "http://localhost:7101/WebServiceSample2-WebService-context-root/GreetingPort";
URL serviceWsdl = new URL(endpoint + "?wsdl");
QName serviceQName = new QName("http://sample2.webservice/","GreetingService");
QName portQName = new QName("http://sample2.webservice/","GreetingPort");

Service proxyService = WsMetaFactory.newInstance(ImplType.JRF).createClientFactory().create(serviceWsdl, serviceQName);
Greeting port = proxyService.getPort(portQName, Greeting.class);

InputStream clientPolicyStream = Servlet1.class.getResourceAsStream("client-policy.xml");
Element clientConfigElem = this.fileToElement(clientPolicyStream);

Map<String,Object> requestContext = ((BindingProvider) port).getRequestContext();
requestContext.put(ClientConstants.CLIENT_CONFIG , clientConfigElem);



In this sample, Greeting is the port interface generated by JDeveloper in the step before.

The parameters to the QName object constructor are the target namespace and the service/port name, both found in the web service wsdl.

3. Attaching the OWSM policy

The OWSM policy is passed as an org.w3c.dom.Element to the requestContext Map. One way to come up with such Element is through an XML file that contains a reference to the actual OWSM client-side policy to be used.

InputStream clientPolicyStream = Servlet1.class.getResourceAsStream("client-policy.xml");
Element clientConfigElem = this.fileToElement(clientPolicyStream);
Map<String,Object> requestContext = ((BindingProvider) port).getRequestContext();
requestContext.put(ClientConstants.CLIENT_CONFIG , clientConfigElem);
Here are the XML file (client-policy.xml) contents. You have to create a file like this and make it available to your application CLASSPATH. It references the OWSM policy to be given to the requestContext Map.
<?xml version="1.0" encoding="UTF-8"?>
<policy-reference uri="oracle/wss11_saml_token_client_policy" category="security"/>


For SAML-based identity propagation, use any of the SAML client policies.

In this case, the policy retrieves the user name Principal from the Java Subject who is running the client and adds it to a generated SAML token in the SOAP call header.

3.1. Switching Identities

To propagate a new identity rather than the one executing the client, use a username token-based policy. By the way, the sample using oracle.webservices.WsMetaFactory may use oracle/wss_username_token_client_policy as the policy name in order to propagate the identity referred by the servlet1-key csf key.

Map<String,Object> requestContext = ((BindingProvider) port).getRequestContext(); 
requestContext.put(SecurityConstants.ClientConstants.WSS_CSF_KEY, "servlet1-key");


“servlet1-key” must match a key entry in the domain-level credential store that holds the username/password pair required for the use case implementation. Here’s how you create a key for OWSM usage in the credential store using wlst:

wls:/offline> connect()
Please enter your username :weblogic
Please enter your password :
Please enter your server URL [t3://localhost:7001] :t3://localhost:7101
Connecting to t3://localhost:7101 with userid weblogic
Successfully connected to Admin Server 'DefaultServer' that belongs to
domain 'DefaultDomain'.
Warning: An insecure protocol was used to connect to the
server. To ensure
on-the-wire security, the SSL port or
Admin port should be used instead.


In this case, the policy retrieves the username/password pair from the credential store and adds it to a generated username token in the outgoing SOAP header.

What if the client is a Java SE application?

So far so good, but what happens when the client runs on a Java SE environment?

a) How do you get a hold of the OWSM policy?

Add oracle_common/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar, available in your middleware home installation, to the client CLASSPATH. All policy files are in it.

b) How to deal with the credential store (for identity switching) ?

You need to supply the client with 2 files:

1 – cwallet.sso, which is a file-based credential store. In order to author cwallet.sso, I recommend that you use wlst’s createCred command. Yes, you’ll need a JRF-enabled Weblogic server to create it.

2 – jps-config.xml, through Java option. In jps-config.xml, make sure there’s a credential store service instance available for the default context pointing to the folder where cwallet.sso is located, as shown in this sample jps-config.xml:

<?xml version = '1.0' encoding = 'UTF-8'?>
<jpsConfig xmlns="" xmlns:xsi="" xsi:schemaLocation="">
<property value="doasprivileged" name=""/>
<serviceProvider class="" name="credstore.provider" type="CREDENTIAL_STORE">
<description>Credential Store Service Provider</description>
<serviceProvider class="" name="idstore.xml.provider" type="IDENTITY_STORE">
<description>XML-based IdStore Provider</description>
<serviceProvider class="" name="policystore.xml.provider" type="POLICY_STORE">
<description>XML-based PolicyStore Provider</description>
<serviceProvider class="" name="jaas.login.provider" type="LOGIN">
<description>Login Module Service Provider</description>
<serviceProvider class="" name="keystore.provider" type="KEY_STORE">
<description>PKI Based Keystore Provider</description>
<property value="owsm" name=""/>
<serviceInstance provider="credstore.provider" name="credstore">
<property value="./" name="location"/>
<serviceInstance provider="idstore.xml.provider" name="idstore.xml">
<property value="./jazn-data.xml" name="location"/>
<property value="" name=""/>
<serviceInstance provider="policystore.xml.provider" name="policystore.xml">
<property value="./jazn-data.xml" name="location"/>
<serviceInstance provider="jaas.login.provider" name="idstore.loginmodule">
<property value="" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
<property value="true" name="debug"/>
<property value="true" name="addAllRoles"/>
<property value="false" name="remove.anonymous.role"/>
<serviceInstance location="./default-keystore.jks" provider="keystore.provider" name="keystore">
<description>Default JPS Keystore Service</description>
<property value="JKS" name="keystore.type"/>
<property value="" name=""/>
<property value="keystore-csf-key" name="keystore.pass.csf.key"/>
<property value="sign-csf-key" name="keystore.sig.csf.key"/>
<property value="enc-csf-key" name="keystore.enc.csf.key"/>
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="credstore"/>
<serviceInstanceRef ref="idstore.xml"/>
<serviceInstanceRef ref="policystore.xml"/>
<serviceInstanceRef ref="idstore.loginmodule"/>
<serviceInstanceRef ref="keystore"/>

Hope this helps some of you dear readers out there.

Achieve Faster WebLogic Authentications with Faster Group Membership Lookups

In my last post  I wrote about the complicated and timely process of determining all of a user’s group memberships when an LDAP namespace includes nested and dynamic group memberships. I wrote about how you can simplify and speed up getting a user’s group memberships through the use of a dynamic “member of” attribute and specifically the orclMemberOf attribute in OID.

Today I’d like to extend this discussion to WebLogic server authentications.

A Review of LDAP Authenticators and Groups

As I’ve written about in the past, as part of the authentication process, LDAP authenticators do a search to determine what groups the user is a member of which in turn get used in determining the group memberships and roles for the JAAS subject and principals.

By default the WebLogic LDAP authenticators follow the long time consuming process I laid out in my last post for determining group memberships with nested groups. First, it searches all your groups to figure out which groups your user is directly a member of. Then for each of those groups, it searches all your groups again to see which of those groups your user is a member of.

It will continue to search your groups with the results of each subsequent search until you reach the configured maximum level of nested memberships that you want to pursue or all the searches come back empty.

Only it is actually quite a bit “worse” than that because for some reason when the authenticator finds a group within a group it doesn’t just use the DN of that group in the next search, it takes the name of that group based on the “group name attribute” setting in the authenticator and then does a search to find the group’s DN all over again. So, for every group found in a search of memberships for the user there will be 2 new LDAP searches performed. One to get the user’s DN again and one to get the groups that group is a member of.

In my post on tuning LDAP authenticators, I wrote about the importance of tuning the settings governing group membership searches in the authenticator and specifically about limiting the depth of the searches for nested group membership.

Speeding Things Up

Today, I’d like to cover how-to dramatically speed up this process by letting the directory do all the work for you. This is achieved by configuring the authenticator to take advantage of the dynamic ‘member of’ (orclMemberOf in the case of OID) attribute that I wrote about in my last post.

The setting that enables this behavior is in the Dynamic Groups section of the provider specific configuration for LDAP authenticators and is called User Dynamic Group DN Attribute. When configured the LDAP authenticator will skip all searches (for both direct and nested memberships) of dynamic groups. Instead it will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.

Here is what you need to know about this setting:

1) When configured the authenticator will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.
2) Despite the fact that the setting is part of the Dynamic Group section of the authenticator configuration, the authenticator will add roles for every group returned as part of the value of the attribute, regardless of whether that group is a static group or dynamic group.

3) That being said, the authenticator will still perform a search of memberships for all static groups even when the User Dynamic Group DN Attribute is defined. It will not however perform a membership search of dynamic groups; instead it assumes all dynamic group memberships are captured by the attribute value.

Note especially that the authenticator will still perform a full search of nested static groups even when User Dynamic Group DN Attribute is defined; even though the orclMemberOf attribute in OID includes static group memberships.
Putting It All Together
So, to dramatically improve your WebLogic authentication performance with nested groups I recommend that you configure your authenticators as follows:

1) Enter the appropriate LDAP attribute name for the value of User Dynamic Group DN Attribute based on the type of directory you are authenticating against.. Appropriate values include orclMemberOf for OID, memberof for DSEE, and ismemberof for AD.

2) Set the value of GroupMembershipSearching to limited. The default value is unlimited.

3) Set the value of Max Group Membership Search Level to 0. This will make the authenticator not perform searches for nested group memberships and limit it to performing a single search to find the users direct group memberships. Again, we will be relying on the value of the attribute specified in User Dynamic Group DN Attribute to give us the nested searches.

4) If you want to even eliminate the direct group membership search you can specify an empty Group Base DN. Note here that the Group Base DN must exist or you’ll get an error and a failed authentication. However, it can be empty. So, you can create cn=fakegroupbase as a sibling of cn=Groups,dc=example,dc=com.

5) If you recall in my previous post I mentioned that using the orclMemberOf attribute can result in duplicate listing when nested memberships are returned multiple times, once for each group that the user belongs to that is a member of another given group. Because of this, you’ll probably want to check the Ignore Duplicate Membership option in the authenticator.

Below is a screen shot of an OID authenticator configured with these options:

LibOVD: when and how

LibOVD, introduced in FMW, is a java library providing virtualization capabilities over LDAP authentication providers in Oracle Fusion Middleware. It is delivered as part of OPSS (Oracle Platform Security Services), who is available as part of the portability layer (also known as JRF – Java Required Files). In other words, if you are a JDeveloper, WebCenter, SOA or IAM customer, you already have libOVD.

LibOVD provides limited virtualization capabilities when compared to its big brother OVD (Oracle Virtual Directory), who is a full-blown server implementing the LDAP protocol with far more advanced virtualization features, including OOTB support for LDAP and database backend servers, advanced configuration for adapters, out-of-box plug-ins as well as a plug-in programming model allowing for almost limitless possibilities in transforming data and connecting to external data sources.

1. When


LibOVD is primarily designed to work as an embedded component for FMW components who need to look up users and groups across distinct identity providers. If you had a chance to look at this post, you already know the User/Role API can take into account only one authentication provider.

Take SOA’s Human Workflow component, for instance. Customers frequently have an external identity store, like OID or Active Directory, holding the application end users and related enterprise groups. But they also often want to keep Weblogic’s embedded LDAP server for administration accounts, like weblogic user.  Or they simply have an LDAP server in the US and another one in Brazil and want to bring all those users together. Using User/Role API alone is not enough.

That does not mean libOVD can be used only by FMW components. It is ok that your custom applications employ libOVD and that’s a given once you enable libOVD for a given domain. However, do not expect any of those features only available in OVD. A common mistake is expecting libOVD to work with a database authenticator. LibOVD is only for LDAP authenticators.

Another use case for libOVD is known as split profile, where information about the same identity exists in more than one LDAP-based identity store and your applications need a consolidated view. More information here:

2. How


LibOVD is activated when you set the property virtualize=true for the identity store provider in jps-config.xml:

<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
<property name="idstore.config.provider" value=""/>
<property name="CONNECTION_POOL_CLASS" value=""/>
<property name="virtualize" value="true"/>
<property name="OPTIMIZE_SEARCH" value="true"/>

It is possible to hand-edit jps-config.xml, but I recommend that you use Enterprise Manager to set it up, because the minimum mistake in jps-config.xml can get the WLS domain into a non-startable state.

Note: Unless your application makes explicit usage of a different JPS Context, this is domain-wide set up, impacting all applications deployed in that domain, both from authentication and user/group lookup perspectives.

Enabling libOVD using Enterprise Manager:

Navigate to the domain Security Provider Configuration screen and click the Configure button, as shown:


Then use the Add button to add the property.


When you enable the virtualize flag, a new folder structure along with some files are created under $DOMAIN_HOME/config/fmwconfig folder.


Notice the default folder name: it refers to the default JPS context in jps-config.xml, which in turn refers to the idstore service instance for which libOVD has been configured.

These are familiar files to readers used to OVD. adapters.os_xml, for instance, lists the configured adapters for libOVD. An adapter is created for each authenticator listed in Weblogic’s config.xml.

3. Be Aware


Within a single adapter, in order to search across both users and groups search bases, libOVD sets the adapter’s root to be the common base between them. For example, let’s say users and groups search bases are defined as cn=users,dc=us,dc=oracle,dc=com and cn=groups,dc=us,dc=oracle,dc=com, respectively. In this case, the adapter’s root is set to dc=us,dc=oracle,dc=com.

Such configuration may cause a performance overhead if customers happen to have more users and groups distributed across other nodes that are also children of the common root but who are not necessarily required by the applications running on Weblogic. Wasted LDAP queries.

Notice the undocumented property OPTIMIZE_SEARCH in the jps-config.xml snippet presented before. It is the solution to the problem just described because it forces libOVD to search only within the users and groups search bases defined in the authenticator providers. No searches are performed elsewhere.

In order to take advantage of OPTIMIZE_SEARCH, make sure to get the appropriate patch for the corresponding release of FMW:

  • FMW 14693648
  • FMW 14919780
  • FMW 14698340

4. Managing libOVD


libOVD can be managed via When connected, type

> help(‘OracleLibOVDConfig’)

and check the available commands.

5. Debugging libOVD


To debug libOVD, create a logger for oracle.ods.virtualization package in your server’s logging.xml file. Here’s a snippet.

<logger name=‘oracle.ods.virtualization’ level=‘TRACE:32’>

 <handler name='odl-handler'/>

My “enable debug logging in OAM” WLST script

I was on the phone with someone earlier today and mentioned in passing that I only need to run a simple script to turn debug logging on and off in my little test environment. The silence on the other end of the line told me either he didn’t believe me …