Connecting Oracle Data Integrator (ODI) to the Cloud: Web Services and Security Policies

Introduction When you look at the list of Technologies listed in ODI 12.2.1 Topology, you can see a new entry: SOAP Web Services. Prior to having this Technology defined here, developers connecting to Web Services in ODI had to enter all the connectivity details in their packages when they designed the Web Service call. Now […]

Using OAAM Risk Evaluation in OAM Authorization Policies

We recently encountered an interesting requirement about taking decision within OAM Authorization policy based on the Risk-evaluation performed by OAAM during Authentication flow. Considering the interesting nature of the requirement / use-case, I thought to share details about the implementation approach through this blog post. All content listed on this page is the property of […]

Part 1: Getting under the covers of Detached Credential Collector (DCC)

Introduction This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. The Detached Credential Collector (DCC) feature was introduced with the release of OAM 11gR2 —   DCC brought some very […]

Chained LDAP Authentication in OAM 11g

Introduction In this post, we look at a simple way to configure a chained LDAP authentication scheme in OAM 11g R2. This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. All […]

OAM 11g Custom Authentication Plugins: Interacting with the Identity Store

Introduction The OAM 11g release includes a powerful authentication plugin framework, which can be used to extend the out-of-the-box authentication schemes, or to implement something completely custom. In this post, we explore how an authentication plugin can interact with the underlying LDAP Identity Store, via a simple example. This post is part of a larger […]

How to secure Web Services exposed by OAAM Server (oaam_server)

At the end it turned out very simple but I had spent long time in configuring security (authentication and authorization) for Web Services exposed by OAAM 11gR2, thought about writing a blog post on it. For native integration, OAAM Server (oaam_server) exposes Web Services. For the enterprise deployment, security of Web Services would be mandatory.  […]

Part 1: Kerberos Authentication, RBAC and SAML identity propagation in OAG

Introduction This post is the first one of a series by Andre Correa and Paulo Pereira on OAG (Oracle API Gateway). Throughout the series, we are going to talk about Kerberos authentication, Role Based Access Control (RBAC) and SAML identity propagation in OAG 11g, formerly known as OEG (Oracle Enterprise Gateway). What follows has been […]

OAM 11g Custom Authentication Plugins: Collecting additional credentials

One of the things that OAM 11g does a very good job of is enabling LDAP-based user authentication, based on collecting username and password from a login form. I’ve seen a lot of questions from the field relating to how to handle more complex, multi-st…

Authenticating OIM APIs without end user’s password

A common requirement in an OIM implementation is to not expose OIM user interface to all types of end users. To address this requirement, usually a custom application using OIM APIs is developed and deployed. Such application will expose specific OIM f…

Unsolicited login with OAM 11gR2

In a previous post Chris Johnson has discussed unsolicited login with OAM 11g.

In OAM 11gR2 this functionality is supported out of the box and with little effort you can implement Unsolicited Login.
This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.


If you’re interested to authenticate using unsolicited POST, please read on…

The complete procedure is explained in the official documentation here, but the docs are not clear on some aspects of the configuration.
To begin with, the documentation states that you have to manually edit the oam-config.xml file, but it does not say where to find it or which one to edit.
In my lab installation, I found six different oam-config.xml scattered across several folders.
After some trial and error I found out that the correct one to edit is OAM_DOMAIN/config/fmwconfig/oam-config.xml
Where OAM_DOMAIN is the WLS domain folder for the OAM domain.
Don’t forget to bounce Admin and Managed Servers after editting the oam-config.xml.
Note that in a distributed environment you want to make changes to the file on the admin server and it will then get pushed out to the managed servers after restarts.
Now all you have to do is post the login info to the endpoint https://oam_host:oam_port/oam/server/authentication.
The required information you need to post to the endpoint is:
  • username
  • password
  • successurl
     If the authentication succeeds, you will be redirected to the successurl you passed to the endpoint.
     In case the authentication fails, you will be redirected to the default OAM error page:
      Now, that isn’t very nice, right?
        If you want to get redirected to a custom error page, for instance, to the same login page with the error message displayed in it so you can try to login again, you just need to edit the Authentication Policy for the /oamDirectAuthentication resource (we will talk about this resource further on).
      To do so, go to Application Domains, IAM Suite, Resources and search for /oamDirectAuthentication.
        Open it and edit its Authentication Policy to include the Failure URL to the page you want to be redirected in case of authentication errors.
        If you don’t want to mess with the default Authentication Policy, which is used by other Resources, you can create another Authentication Policy for this resource and make the required changes.
        To display the errors messages, check out the docs about creating Custom Error Pages here 
        To test the whole thing, you can use a simple JSP to post the info to OAM:
        And for the JSP of the success URL I print all the request parameters, headers and session attributes:
         From this point on, you’re already authenticated to OAM and you can access any resources you’re authorized to.
        The documentation also describes how you can combine different HTTP operations (POST, GET, DELETE, etc) with different Authentication Schemes (FORM, CERT, etc).
        If you have specific requirements for the unsolicited login, you can create/edit the /oamDirectAuthentication Resource of IAM Suite Domain. This resource controls all the specifics of unsolicited authentication, for example, allowing only for HTTP POST and FORM based authentication.
        The resource /oamDirectAuthentication is a virtual resource that is defined in the system that represents the physical endpoint for unsolicited login. 
        So, when it comes to policy configuration you will always deal with /oamDirectAuthentication, however when it comes to the physical endpoint (the actual servlet URL for posting information) you will use /oam/server/authentication.


Password Policy in OAM 11g R2

One of the features in the new 11G R2 (or 11.1.2) release of Oracle Access Manager that’s been most eagerly anticipated is the support for password policy within the OAM product; that is, the ability for OAM itself to support a subset of pass…

OIM 11g R2 & X.509 authentication

OIM 11g R2 is out! This release brings a lot of new features and also improvements to existing features.OIM authentication providers are among the ones that were improved. The improvements make easier to integrate OIM with SSO solutions (for both SSO p…

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:

Unsolicited login with OAM 11g

In a previous post I talked a little about protecting only a part of an application with OAM. I included this bit of text describing the use case: But what if you want to let users access part of the app anonymously, but require them to log in to acce…

Couple of things you need to know about the User/Role API

The idea of the User/Role API is to abstract developers from the identity store where users and groups are kept. A developer can basically interact with any identity provider supported by Weblogic server using the same methods. The javadoc can be found here:

In this post I want to alert you about two caveats:

1) User/Role API is able to query data from only one provider. If you want to query multiple identity stores, you need to go through an OVD Authenticator (or libOvd). And depending on how you get a handle to the identity store, the order in which providers are defined in Weblogic server Console as well as their CONTROL FLAGs do matter.

Shamelessly borrowing content from FMW Application Security Guide:

“OPSS initializes the identity store service with the LDAP authenticator chosen from the list of configured LDAP authenticators according to the following algorithm:

  1. Consider the subset of LDAP authenticators configured. Note that, since the context is assumed to contain at least one LDAP authenticator, this subset is not empty.
  2. Within that subset, consider those that have set the maximum flag. The flag ordering used to compute this subset is the following:

    Again, this subset (of LDAPs realizing the maximum flag) is not empty.

  3. Within that subset, consider the first configured in the context.

    The LDAP authenticator singled out in step 3 is the one chosen to initialize the identity store service.”

Lack of such understanding is a big source of headache.

Weblogic server ships with DefaultAuthenticator as the out-of-box authentication provider with the CONTROL FLAG set as REQUIRED.  Customers typically want to retrieve users from an enterprise-wide LDAP server, like OID or Active Directory. They go ahead and define a new authenticator and put it as the first in the providers list. But they leave DefaultAuthenticator untouched, because they still want to leverage the weblogic user as the administrator. And when some application relying on the User/Role API is executed (Oracle’s BPM and BIP are examples), a problem is just about to happen, because none of the users and groups defined in the enterprise-wide identity store are found. And the solution to this is pretty simple: switch DefaultAuthenticator’s CONTROL FLAG from REQUIRED to SUFFICIENT. What happens now during authentication time is that if the user is not found in the first authenticator, the lookup falls back to DefaultAuthenticator, so leveraging weblogic user is not a problem. And that will also make the User Role API querying the identity provider that you want (the first in the list).

2) Depending on how you get a handle to the identity store, provider-specific metadata (user, password, address, root search base) won’t be reused and you’ll be forced to define it in code again (of course you can externalize them to some properties file, but it is still a double maintenance duty).

That said, let’s examine possible ways of getting a handle to the identity store.

IdentityStoreFactoryBuilder builder = new IdentityStoreFactoryBuilder();
IdentityStoreFactory oidFactory = null;
Hashtable factEnv = new Hashtable();
// Creating the factory instance
factEnv.put(OIDIdentityStoreFactory.ST_SECURITY_PRINCIPAL, “cn=orcladmin”);
oidFactory = builder.getIdentityStoreFactory(“
OIDIdentityStoreFactory”, factEnv);
Hashtable storeEnv = new Hashtable();
IdentityStore oidStore = oidFactory.getIdentityStoreInstance(storeEnv);
// Use oidStore to perform various operations against the provider

Look at how specific this snippet is to OID and how we’re passing metadata that is already available in the provider definition itself. By doing this, you do not incur in the problem described in my bullet #1, because you’re going directly against a specific identity store. You’re not leveraging the definitions in Weblogic server at all.

But if you do this…

JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFactory.getContext();
LdapIdentityStore idstoreService = (LdapIdentityStore)ctx.getServiceInstance(IdentityStoreService.class)
IdentityStore idStore = idstoreService.getIdmStore();

// Use idStore to perform various operations against the provider

you’re delegating the provider lookup process to OPSS (Oracle Platform Security Services), and it will abide by those rules outlined in my bullet #1. Here, you don’t have to redefine your connection metadata. You are simply reusing whatever is defined in Weblogic server and are not incurring in the problem mentioned in bullet #2. For consistency and manageability, this is a much better approach.

For the curious, the following is the necessary configuration in jps-config.xml to make this happen (see text in bold red). It is out-of-box available in any FMW install, so don’t worry about it.


<serviceInstance name=”idstore.ldap” provider=”idstore.ldap.provider”>
     <property name=”idstore.config.provider” value=””/>
     <property name=”CONNECTION_POOL_CLASS” value=””/>


<jpsContexts default=”default”>
        <jpsContext name=”default”>
            <serviceInstanceRef ref=”credstore”/>
            <serviceInstanceRef ref=”keystore”/> 
            <serviceInstanceRef ref=”policystore.xml”/>
            <serviceInstanceRef ref=”audit”/>
            <serviceInstanceRef ref=”idstore.ldap”/>
            <serviceInstanceRef ref=”trust”/>            
   <serviceInstanceRef ref=”pdp.service”/>


Enterprise Gateway (OEG) External Service Calls

I’ve had the opportunity recently to work with the Oracle Enterprise Gateway (OEG) for a DoD opportunity.For those that aren’t familiar, OEG is an OEM from Vordel.The definitive blog on Vordel is at where our old friend Josh Bregman writes.There were a couple of patterns that emerged in my work that I wanted to post.

One pattern is the need to make an external call to a service.In my case, I needed to call to an attribute sharing service (See Chris’ blog on XASP for more details on one approach for this) and a XACML PDP.Note, OEG has an embedded PDP solution using Oracle Entitlements Server (OES) that provides a faster service, but in my case, I had to stay with the standards-based solution.This is very easy to accomplish with OEG with a 3-step circuit:







The Set Message defines the parameters of the request.In my case, I have an attribute service that takes a user DN and returns specified attributes.

<SOAP-ENV:Envelope xmlns:SOAP-ENV=””>


<orafed-arxs:AttributeRequest xmlns:orafed-arxs=”″ TargetIDP=”SpaceFenceIDP”>


<orafed-arxs:Attribute Name=”mail”/>

<orafed-arxs:Attribute Name=”clearance”/>




Notice the wildcards with ${variable}.These were attained earlier in the circuit with a “Retrieve from Directory Server” node after authentication to the Gateway.In the Policy Editor, create a policy and drag the Set Message onto the easel.Enter “text/xml” for the Content-type and optimally, import the request from a file, then save.








Setting the URL is very straightforward, just enter the URL and any trust certificates if necessary.

The response from the attribute service (Oracle Identity Federation in this case) is:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=””>


<orafed-arxs:AttributeResponse CacheFor=”1499″ xmlns:orafed-arxs=”″>


<orafed-arxs:Subject>cn=Jane Wilson,ou=CDC,dc=service,dc=mil</orafed-arxs:Subject>

<orafed-arxs:Attribute Name=”mail”>



<orafed-arxs:Attribute Name=”businessCategory”>






Knowing this response format will help in parsing the response in OEG.When editing “Retrieve from Message”, re-name the node appropriately and select “Add” under the attribute location.





Name the attribute (arbitrary) and select magic wand button.Browse to the response file saved on disk, and you should see the contents in the XPATH Wizard.Select the node which you wish to have returned to the gateway.









Select “Use this path” and the XPath Expression should show up in the XPath field.Select OK.Name the attribute you want to populate in the gateway and save the node.

Debugging on OEG typically consists of adding a “Trace” node to your circuit and putting the listener in DEBUG or DATA mode.This gives you the “System.out” visibility into what’s going on in the Gateway.

Thanks to Dave Roberts from Vordel for getting me over the humps and for stealing second in 2004.

Non-Standard approaches to SOA Identity Propagation and Authentication

I wanted to take some time to talk about a couple non-standard approaches to identity propagation and authentication that I sometimes see people take when building their web services.

These approaches are non-standard both because they well… don’t utilize the large body of standards that exist for web service security and because they are outside of what would probably be considered best practices by most people in the industry.

Custom Security Headers

It is fairly common to see people develop services that require authentication through a custom security header.

Now, if your service will consume a token that is truly custom, which is to say outside the standard token types defined in the WSS specs, then this is a perfectly reasonable approach. A good example of this would be a service that can consume a web SSO token from Oracle Access Manager.

This approach is especially powerful if your service can consume the custom token plus one or more of the standard tokens. One example would be a service setup to consume the Oracle Access Manager cookie or a standard username token.

However, one mistake you often see people make is to hard code in a required custom security header that is in essence the same as one of the standard WSS authentication methods. Usually, it is a custom security header that just holds a username and password, which makes it equivalent to the WSS username token.

There are several reasons developers take this approach but they mostly center on not understanding the flexibility and value of the security functionality that is already built into the container that is running their service. For example, sometimes developers will say that they need a custom token since the container will only compare the username in username token to the UID attribute in the directory, which is simply not the case.

Even if custom handling of authentication is required, it is still better to utilize a standard token (with custom handling) over a custom token.

Another mistake you see people make is once they decide they need a custom token, they will just turn off security at the container level and process the token inside of their service. It is far better for custom authentication code to live inside of the container than in the service itself. Staying with the container for security will:

  • Allow you to easily use your custom token with other services
  • Allow you to switch to a standard authentication method down the road
  • Keep you compatible with authorization and auditing done at the container level which you may want to keep even if you need to do custom authentication.

I’d propose the following hierarchy of approaches to web service authentication and identity propagation, going from most ideal to least ideal:

  1. Use of standard authentication tokens that are processed by the container’s out-of-the-box functionality.
  2. Use of standard authentication tokens that are processed by custom code in the container.
  3. Use of custom authentication tokens/headers that are processed by custom code in the container.
  4. Use of custom authentication tokens/headers that are processed by code in the service itself.

Propagating Identity in the SOAP Request Body

The second approach I’d like to discuss is specific to propagating an identity from a web app or service to a “downstream” service. The approach is simply to stick the user identity into the body of the request and consume it with custom code in the service. Now obviously, this approach is inherently insecure on its own, but it is an appropriate option in situations where the client of the service can be trusted. Usually this trust will be justified by the security that is present at the transport or network level.

Sticking a user identity into the body of the request is really analogous to use of the SAML bearer confirmation method which I discussed in my first post on this blog.

So, it is probably most useful to think of its appropriateness in the same terms. In the blog post on the bearer confirmation method I discussed some advantages that it had over just sticking the user identity into the request body. Now, I’d like to turn the table and look at some possible advantages putting the identity in the request body sometimes has over SAML with bearer and over creating a custom security header of a similar ilk.

Now, you are probably saying to yourself: Hold on Brian, you just laid out a hierarchy with using standards and container functionality at the top and custom approaches executed in the service code at the bottom.

Well that is true, but there is a reason that putting the identity in the request body and extracting it in the service should sometimes be considered. The main problem with SAML with the bearer confirmation method is a lack of support for it. This lack of support applies not only to server side WSS stacks but, perhaps even more importantly client side stacks. If you are creating a service that may be widely consumed and are operating in a very heterogeneous environment where client side developers maybe be using any number of different software packages for their development, then SAML with bearer may be the wrong choice for you. Likewise, it may be harder for consumers of your service to create a custom security header than to just stick the identity in the request body. Along similar lines, it may be easier to convey the format you want to use for the user identity in the WSDL if the identity is being put in the body.

The final consideration for whether propagating the identity in the request body is a good way to go centers on how many services you might have where such trusted identity propagation is deemed as acceptable. If you have a huge SOA infrastructure with tons of applications consuming tons of internal services then it probably makes sense to standardize on bearer or develop a custom security header and corresponding container plug-in to consume the header.

However, if you only have one service that fits this description and SAML with bearer isn’t supported by your stack, then it may be hard to justify the added effort of developing a custom token. In that case, just sticking the user identity in the request body may be the best way to go.

Configuring Spaces to authenticate with Active Directory

WebCenter Spaces 11g was released on July 1, 2009.  It is a collaboration platform, built on top of Oracle WebCenter 11g. I recently went through the process of setting it up for a client, and integrating it with Microsoft technologies … Continue reading