What the World Needs Now is Open Az

In a series of customer conversations over the last few weeks, there seems to be two schools of thought around externalized authorization. I covered this in some detail in To Cache or Not to Cache. I have a little more perspective on the "To Cache" approach.

The reality is that today most applications cannot externalize their authorization decisions to a 3rd party/centralized authority. They can externalize their group memberships to LDAP, but the core entitlements are baked into the application either in the form of code or in some application database tables. So give this reality, which of the two approaches - build a centralized service and get people to modify their applications to call your service or manage entitlements centrally and push them to the existing application stores is going to be easier for applications to adopt?

To be clear, there is no issue with either approach from either an architectural or Oracle product perspective. Both are fine. I think the bigger issue is why applications have to have their own entitlements store to begin with? I think one answer is that their is no standard mechanism for externalization.

But Josh, isn't that what XACML is for? Yes, but as we've discussed in this blog, WebServices security and interoperability is not as simple as having a standard. Also, the thought of having to make a SOAP call for every authorization request could present some performance challenges.

My hope is that OpenAz (which is introduces a Java runtime binding on-top of XACML) will drive more packaged applications to look at externalization. The Java binding is easy to write to and doesn't necessarily assume that the service is a remote SOAP endpoint. The OpenAz policy decision implementation, by default could just look into the application database tables. This allows large enterprises that have multiple packaged applications to swap out application specific look ups into a centrally managed authorization model. This would benfit firms greatly, as having centralized management of entitlements can greatly simplify compliance and audit reporting.

Though we're just getting started with OpenAz, but its re-assuring to talk to customers and receive validation of the problem that we're looking to address.

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.

Another Reason Why People Don't Really Use HTTP Basic Authentication

If you are using WLS behind a Web SSO solution and you are authenticating users with BASIC AUTH, and the resources are not protected in WLS

or doing your own programmatic authentication from inside a servlet/JSP

then you need to pay attention to the enforce-valid-basic-auth setting for WLS. In version 9.2. or later, the default behavior is to attempt to validate basic credentials that the browser is sending, even if the resource is unprotected.

As an alternative, give your end-users a decent experience and give them an HTML form.

The New WebLogic Server Book is Almost Here

The WebLogic Server Book is almost here, or more specifically my piece - the security chapter - is done. I literally just finished the samples - the online material that is the companion to the book. The samples include fully scripted SAML 2.0 for both WebSSO and for SAML Token Profile (Web Services), JAAS authentication, core JEE security and WLS custom application security. I wanted to do SPNEGO, but the target platform is XP, so not really practical.

Well, I'm off to NYC tomorrow (instead of home back to Boston), to go cover one of my favorite topics - fine grained entitlements for financial services customers. This is an extension of the discussion/architecture from last month, so I'm looking forward to it. I'll be taking the train back from NYC, so maybe I can get caught up on some posts that have been backed-up behind work, and getting book wrapped up.

"What is the point of all this?"

A truly great question. I'm here at Oracle HQ presenting to a set of very smart architects, discussing message level security, and this is the question.

"Why go through the trouble of message level security if the service is behind the firewall?"

"The service is just accessed using HTTPS and Basic Authentication. What's wrong with that?"

The topic of message-level security vs. transport level/network level security is interesting (and not new). So here's my two cents:

Simpler is better - if you can get away with SSL or network level security - good for you.

So, this begs the question, what use cases require message level security. This is not an exhaustive list but, a few simple guidelines:

Asynchronous - especially long running transactions - having security in the message makes sense. Things like SSO cookies and SSL sessions will timeout.

Multi Party - transport is typically point to point, so you can encrypt something for one person - but not many parties. WS-Security supports the encryption of parts of the message.

"Truly Loosely Coupled" - In SOA, if you want to be able to send the message to any service, you can't count on what security controls other parties may provide, so if there is confidential information, best to encrypt it in the message.

Federated - When the message is going to change security domains (read: networks), conveying who the user and the calling service can easily be contained in the message using SAML. This use case is extended to include attributes. This use case assumes that in the other network it may be hard/impossible to validate the user's credentials, so trusting the message is the best bet.

So, if you're doing simple REST style services (stateless/synchronous) or RPC style API calls, look at the transport level - its probably sufficient and it is simple. Message level security introduces some additional complexity and effort, but is absolutely required to address many real-world use cases.