Speeding up your OES-enabled app

When you secure a WebLogic app with OES or use OES to secure a Java based application using the Java Security Module the overhead and performance impact is minimal (it's usually measured in microseconds). In fact most customers report that OES is faster than the code it replaced.

When you use OES' Web Services Security Module your application makes SOAP or RMI calls over the network to a central server or cluster of servers. This is inherently slower than in process calls, not because the Web Service SM is slow, but because SOAP, XML, and SSL all add computational overhead, and network communication adds latency. Consider that a simple ICMP ping is measured in milliseconds and it's clear that this might be a fairly large impact on your application.

When an application calls OES there is a single, common Java API you can use regardless of which SM you are using. At its simplest the API takes three parameters - action, resource and context data - and returns a boolean along with context data. Programmers new to OES will often go no further than making calls to this API and if you are using the Java Security Module, which runs in the same process space as your application logic, you need go no further.

But if your making SOAP or RMI calls you'd be doing yourself a disservice by not looking further.

OES offers two additional API calls that allow you to make bulk authorization calls. One (isBulkAcessAllowed / isBulkAccessAllowed) allows you to send a batch of action/resource and context calls and get a list of true/false responses. The other (isChildResourceAccessAllowed / isChildResourceAccessAllowed) allows you to ask OES for a list of resources it knows about that the user is authorized to access.

These interfaces are also available in the WSDL and the .NET example shows how you can make these calls from C#.

OES discovery mode

How do you enable Discovery Mode in Oracle Entitlements Server?

from the documentation:

The ASI Authorization and ASI Role Mapping providers support a Discovery mode that helps make this task easier. Typically, these providers answer questions about security, but when in Discovery mode, the providers record information about those questions to build your policy (for example, what privileges and resources must be granted to view a particular web page).

To use Discovery mode, you must modify the command line that starts your Security Service Module by adding the following system properties:

com.bea.security.providers.authorization.asi.AuthorizationProviderImpl.discoverymode=true
com.bea.security.providers.authorization.asi.RoleProviderImpl.discoverymode=true

More information about discovery mode is in the ALES 3.0 documentation

ADF and OES, part one of many

Before I get into the guts of a post allow me to introduce myself. I'm Chris Johnson (nice to meet you) and, like Josh and Brian, am a member of the Fusion Middleware Architecture Group; AKA the A-Team (cue theme music here). When Josh started this blog he invited me to join in and I promised to do so. Today I make good on that promise with this, the first of a number of posts on using OES to secure an ADF Web Application. This post will cover getting an OES enabled WebLogic domain to startup properly and run your ADF based web app. The second post will show how to write OES policies to protect URLs. And finally in the third post I'll discuss how to really dig down into the app and apply OES' fine grained access control to secure links, buttons, tabs and other components.

Oracle Entitlements Server is a product that we've discussed here before. For new readers the quickest way to describe OES is as a way to take all of the authorization logic out of your application and put it in a better tool with central configuration and management. OES is to the authorization logic as something like OAM or SiteMinder is to the login code you used to keep in your application.

Oracle Application Development Framework (ADF) is "an end-to-end Java EE framework that simplifies development by providing out of the box infrastructure services and a visual and declarative development experience." ADF is a complete framework for developing applications, but the easiest bit to bite off first is ADF Faces. If you're familiar with JSF you can think of ADF as a bunch of really high quality AJAX based UI components for JSF plus a great development environment (JDeveloper) plus a bunch of other stuff to make your life easier.

ADF has a security framework can be used on its own or in conjunction with OES but in these posts I'm going to pretend that ADF just JSF. I'm doing this intentionally for a number of reasons, the most important of which is a desire to document and describe how to use OES with JSF alone. Truth be told another part is that while I know quite a bit about OES I actually know fairly little about ADF since I just began using it to build my OpenWorld demonstration part time a couple of weeks ago. I'll be telling you more about my session in another post soon enough.

As with all posts on this site please remember to check the current support status of the products before planning a production deployment. As of this writing the OES Security Module for WebLogic is not currently supported on WebLogic 11g R1, but as Josh mentioned in the first of his OES + SOA Suite posts it does seem to work just fine.

The basic environment I'm using is:

• Oracle Enterprise Linux
  
• WebLogic 11g R1
  
• Oracle Entitlement Server 10gR3 Admin Server (with CP2)
  
• Oracle Entitlement Server 10gR3 Security Module (with CP1)
  
• JDeveloper 11g R1
  

I created my application in JDeveloper and was able to test as I went along with the built in WebLogic Server. Once I reached a reasonable point I wanted to deploy it into a standalone OES-enabled WebLogic Server domain. The steps I took were:

1. Create a WebLogic domain using the Configuration Wizard
   
2. use the OES Config Tool to create your SSM instance and load the basic policies needed to boot the domain
   
3. switch the default security realm back to myrealm
   
4. boot the domain
   
5. use the WebLogic console to adjust the security providers so that OPSS will work
   
6. switch the default security realm back to OES
   
7. boot your domain
   
8. celebrate
   

The first couple of steps are well documented elsewhere, but I'll cover them quickly here just for completeness.

Create WebLogic Domain
The Fusion Middleware Configuration Wizard will create a new WebLogic Server domain or extend an existing domain. On Windows you can find that tool in your Start Menu, on Unix it's in Oracle/Middleware/wlserver_10.3/common/bin/config.sh. Because ADF uses the Java Runtime Framework (JRF) if you're using ADF rather than simple JSF pages remember to check the JRF box when creating your WebLogic Domain!

Use the Config Tool to create an SSM
The OES ConfigTool will create an SSM instance, load the policies necessary to boot the WebLogic domain and will configure WebLogic to use the OES Database Authenticator as well as the Authorization, Role Mapping and Audit Providers.

If you try to start your WebLogic Server at this point you'll get an exception from oracle.security.jps.JpsException "Exception while getting default policy Provider". If you read through the error you'll see another error "No Default or LDAP Authenticator configured on WLS". Josh discussed using the Default Authenticator and I want to use LDAP anyway so...

Switch the default security realm back to myrealm
Make a backup of the config/config.xml file, then edit the original with Notepad, vi, emacs or any other plain text editor. Search for the line that contains default-realm and change the value from whatever it currently says to myrealm but take careful note of the value you have there as you will need it later.

Boot your domain
run startWebLogic.sh/.bat and boot your domain

Adjust the WebLogic Security Providers
I already mentioned that Josh discussed the DefaultAuthenticator so here's my shameless copy/paste of what he said:

Next, log into the weblogic console http://localhost:7001/console, and create the DefaultAuthenticator and the DefaultIdentityAsserter. Set the JAAS Control Flag on both the DefaultAuthenticator and the DatabaseAuthenticator to SUFFICIENT and order the DefaultAuthenticator first (I'll explain why in a second).

Oh, so the reason for having to have a specific ordering on the authentication providers, and having the DefaultAuthenticator first and sufficient is that the DatabaseAuthenticator adds a special IdentityDirectoryPrincipal, that JDeveloper doesn't have the classes - so I simplified this by "tweaking" the realm. In practice, the DatabaseAuthenticator is not really used, but it is the authentication provider that is created by default in the configtool. This is really just a minor issue, but I wanted people to understand why the change.

If you're going to use JDeveloper to deploy your app to the domain then you should follow his instructions. If you've already deployed the application to the domain or don't plan to use JDeveloper to do that you can go ahead and plug in an LDAP Authenticator instead.

In any case remember to set the order properly and make the DefaultAuthenticator sufficient if you use it. Once you've made the changes shut the WebLogic Server down.

Switch the default security realm back to OES
Edit config.xml again, being sure to reload it from disk to pick up the changes we made a moment ago. Again find the default-realm and change the value back to what was there originally.

Boot your domain
Run startWebLogic again and the domain should startup normally. Wait until you see it reach the RUNNING state before pouring your margarita, martini or beer, then by all means enjoy!

Next up - securing your JSPs, Servlets and JSF pages with OES.