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.

Who’s that knocking at my door (or web service)?

In the web application security world it is pretty easy to define whom the user of the application is; he or she is the person clicking on the browser and generating requests to your web application.

In the SOA / web services world, where identity propagation is one of the main concerns of those thinking about security, things are not so clear-cut. With web services we are often not concerned with who the end-user of our application is but rather who or what the client of our service is. This client is likely to be the application that is interacting with an end-user or even another web service.

In many cases our service or the authorization policy protecting our service may require the identity of both the ultimate end-user of the enterprise application using our service and the identity of the application itself.

I believe that the factors for determining whether the end-user identity, application / web service client identity, or both are required lie more with what the web service does than with other common security factors such as whether the web service is externally exposed or not.

For instance if I was making a service to publish live updates of the score of my local high school’s football games to trusted media partners, then I’d care about the identity of the applications consuming my service and probably not about the end users of my media partners applications. On the other hand, a web service for a concert ticket exchange must know about both the end user and the client of the service.

There are many ways in which these different identity propagation scenarios can be accomplished using Fusion Middleware products. Josh and I have been spending a lot of time focused on this subject and will be sharing further thoughts and specific “how-to” examples in the coming weeks.

In the mean time, we are very interested in hearing your thoughts on this subject.

OWSM Client Policies and SAML - Simpler is Better

Classic example of me being "too clever by half".

From the OWSM Documentation

Looks like you can just set the username as a property

URL localURL =
    new URL("https://.../MyWebServicePort?WSDL");

    QName name = new QName("http://view.team2.oracle.com/","MyWebServiceService");
  
  myWebServiceService =
    new MyWebServiceService(localURL,name);

  final weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature securityFeature =
        new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss_saml_token_bearer_over_ssl_client_policy");

  WebServiceFeature[] features =
    new WebServiceFeature[] {securityFeature};

  MyWebService myWebService =
    myWebServiceService.getMyWebServicePort(features);

  
  Map<String,Object>  reqContext = ((BindingProvider) myWebService).getRequestContext();
  reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe");
  

  // Add your code to call the desired methods.
  System.out.println(myWebService.helloThere("From a Java client - JDOE"));

This "AH HA" eliminates the need for the code to get the JAAS Subject and the configuration of the jps-config.xml and system-jazn-data.xml. Much better.

Just to round out, here is the client for SAML sender-vouches.

URL localURL = new  URL("http://oamwindows:7001/Team2-ViewController-context-root/MyWebServicePort?WSDL");

    QName name = new QName("http://view.team2.oracle.com/","MyWebServiceService");
  
  myWebServiceService =
    new MyWebServiceService(localURL,name);

  final weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature securityFeature =
        new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature("policy:oracle/wss10_saml_token_with_message_integrity_client_policy");

  WebServiceFeature[] features =
    new WebServiceFeature[] {securityFeature};

  MyWebService myWebService =
    myWebServiceService.getMyWebServicePort(features);

  Map<String,Object>  reqContext = ((BindingProvider) myWebService).getRequestContext();
  reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe");


  reqContext.put(ClientConstants.WSSEC_KEYSTORE_LOCATION, "c:/wstest/alice.jks");
  reqContext.put(ClientConstants.WSSEC_KEYSTORE_PASSWORD, "password" );
  reqContext.put(ClientConstants.WSSEC_SIG_KEY_ALIAS, "alice" );
  reqContext.put(ClientConstants.WSSEC_KEYSTORE_TYPE, "JKS" );
  reqContext.put(ClientConstants.WSSEC_SIG_KEY_PASSWORD, "password" );
  reqContext.put(ClientConstants.WSSEC_ENC_KEY_ALIAS, "alice" );
  reqContext.put(ClientConstants.WSSEC_ENC_KEY_PASSWORD, "password" );
  reqContext.put(ClientConstants.WSSEC_RECIPIENT_KEY_ALIAS,"bob");

  System.out.println(myWebService.helloThere("From a Java client"));

I did all of my testing with the demo CA that ships with WebLogic Server. I find the CertGen and the ImportPrivateKey
tools to be really useful in building small samples. I created two keystores - alice.jks and bob.jks. Alice for the client and Bob for the server. This is all standard stuff, but one thing to remember that OWSM has only a single identity and trust store...not separate stores as in J2SE or WLS, so I had to add the CertGenCA.der to both keystores.

Beyond on that, really pretty simple. I configured the bob.jks keystore for the WebLogic Server Domain from EM - Domain (Right Click) -> Security -> Security Provider Configuration. Scroll down to Keystore...configure bob.jks as the store. Restart the server. Send the message and it just works!

OWSM stand-alone Client to OWSM Server doing SAML Bearer and SAML Sender-Vouches - check!

SAML Bearer Confirmation - An example using OWSM Client Policy

This is an extension of the discussion started by Brian in his inaugural post here at the FusionSecurity blog. Brian and I, along with other members of the A-Team were out at HQ getting some training on the SOA Security capabilities in 11g, and I wanted to share a useful "How-To" from that week.

First, let me show you the code, and then I'll take you through the code in some details and explain the additional set-up required to make this use case work. Basically, the code is for a stand-alone Java client using OWSM client policies to enable a JAX-WS Web Service Proxy to use SAML Bearer over SSL - quite a mouthful!

The Code

package com.oracle.team2.view;

import java.net.URL;
import java.security.AccessControlContext;
import java.security.AccessController;
import java.security.PrivilegedAction;
import javax.security.auth.Subject;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.LoginContext;
import javax.xml.namespace.QName;
import javax.xml.ws.WebServiceFeature;
import javax.xml.ws.WebServiceRef;
import oracle.security.jps.JpsContext;
import oracle.security.jps.JpsContextFactory;
import oracle.security.jps.service.login.LoginService;

public class MyWebServicePortClient {
@WebServiceRef
private static MyWebServiceService myWebServiceService;


public static void main(String[] args) throws Exception {

URL localURL =
 new URL("https://.../MyWebServicePort?WSDL");

QName name =
 new QName("http://view.team2.oracle.com/", "MyWebServiceService");

myWebServiceService = new MyWebServiceService(localURL, name);


JpsContextFactory factory =
 JpsContextFactory.getContextFactory();

JpsContext jpsContext = factory.getContext("Client");
LoginService loginService =
 jpsContext.getServiceInstance(LoginService.class);


CallbackHandler cbh = new MyAssertionCallbackHandler("josh");

String[] selectiveModules = new String[] {
    "user.assertion.loginmodule"
};
LoginContext ctx =
    loginService.getLoginContext(new Subject(), cbh, selectiveModules);
ctx.login();
Subject s = ctx.getSubject();

final weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature securityFeature =
   new weblogic.wsee.jws.jaxws.owsm.SecurityPolicyFeature(
"policy:oracle/wss_saml_token_bearer_over_ssl_client_policy");


Subject theSubject =
  Subject.getSubject(AccessController.getContext());

System.out.println("The Subject is " + theSubject);


AccessControlContext acc =
 AccessController.getContext();

Subject.doAs(s, new PrivilegedAction() {


 public Object run() {
   WebServiceFeature[] features =
     new WebServiceFeature[] { securityFeature };

   MyWebService myWebService =
     myWebServiceService.getMyWebServicePort(features);

   // Add your code to call the desired methods.
   System.out.println(
myWebService.helloThere("From a Java client"));

   return "done";
 }
});

}
}

The Explanation

We're applying OWSM client side policy, that requires a SAML Assertion - Bearer and that the request is over SSL. The SSL implementation is the standard J2SE and OWSM uses the JAAS Subject for the identity. The policy is applied via the WebServiceFeature and is described in the OWSM documentation.

Basically, we're using OPSS inside of a J2SE client to establish the JAAS Subject, without providing a password. I used the OPSS documentation as a reference. I used exactly the MyAssertionCallbackHandler from the documentation.

The final "trick" is that the call to the web service is done inside of a call to Subject.doAs(Subejct,PriviledgedAction). This pushes the Subject from the LoginModule on to call stack, and makes it available for the OWSM policy.

The Configuration

So, there a few command line arguments that need to be passed to this client:

-Djavax.net.ssl.trustStore=truststore -Djavax.net.ssl.trustStorePassword=123456

There are the standard J2SE SSL parameters. The JAX-WS client uses the standard SSL.
In my example, I just used the DemoIdentity and DemoTrust, so I set my -D's to

-Djavax.net.ssl.trustStore=C:\\Oracle\\Middleware\\wlserver_10.3\\server\\lib\\DemoTrust.jks -Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase

You also have to pass the program the location of the jps-config.xml.

-Doracle.security.jps.config=c:\jps-config-jse.xml

The jps-config.xml defines the Oracle Platform Security (OPSS) services used by the client. In our use-case, we're going to be using the LoginService to establish an identity for the client. I got the basis of the jps-config-jse.xml from DOMAIN_HOME\config\fmwconfig\jps-config.jse.xml.

At the end of this file, you need to add a jpsContext called Client that contains a reference to the user.assertion.loginmodule

<jpsContext name="Client">
<serviceInstanceRef ref="user.assertion.loginmodule"/>
</jpsContext>

The user assertion login module allows the client to create an identity for the user with no password. It won't work with any username - the user still has to be found in the identity store, which in this case is stored inside of the system-jazn-data.xml. By default, the login module is looking for the system-jazn-data.xml found in the same directory in the jps-config.xml.

I found the system-jazn-data.xml reference useful in building this file:

<jazn-data>
<jazn-realm>
<realm>
<name>jazn.com</name>
<users>
<user>
<name>josh</name>
<guid>1</guid>
</user>
</users>
</realm>
</jazn-realm>
</jazn-data>

The final, configuration step is to make sure that the user that you're asserting - in this case "josh" exists on the server side in WLS. You can just add the user via the WLS admin console.

The Wrap Up

This is definitely a little tricky, but it demonstrates how to use a SAML Bearer assertion. There is no PKI required on the client side - simply the ability to trust the server at the transport level. This is pretty straight forward and simpler then setting-up either sender-vouches or holder-of-key. Consider using this type of approach from within a trusted network.

Bearer Confirmation Method (Huh! What is it good for…)

For starters, allow me to introduce myself. My name is Brian Eidelman and I am a new member of the Fusion Middleware Architecture Group (a.k.a the A-Team) and a new contributor to this blog. Since the memo has gone out that in addition to security we will be discussing dogs now, I'd like to introduce my faithful companion Coco.

Now without further ado, my post:

The WSS SAML Token Profile Specification defines several “confirmation methods” by which the contents of the SAML assertion can be linked to the SOAP message content itself. In other words the method of proving that the assertion really goes with the message that it is being sent in.

The “bearer” confirmation method is sort of peculiar in that it defines no process at all for proving the link between the contents of the assertion and the message content. Rather, the link is to be implicitly trusted.

At this point you may be saying to yourself, if there is no means of verifying that the SAML assertion goes with the message, then what good is it?

Well, the trust can be implicit for any number of reasons. It could just be that trusting developers created the service. More likely however, the link between the SAML assertion and the message can be implicitly trusted by the service because the integrity of the link has been delegated to some other external factor; usually to the network level.

In some cases we could be talking about an internal network setup so that all requests to the service are guaranteed to come from a tamper proof trusted client (if you aren’t buying into this, just humor me). In other cases we could be talking about SSL with 2-way authentication. The point is that the service can trust that only a proper trusted client can successfully get a message to it in the first place.

Now at this point you might be thinking to yourself, fine but then how is SAML with bearer confirmation different than just including a username token with no password in the message header.

Well, SAML with bearer confirmation offers a few additional advantages over the plain old username token. Foremost, the assertion can contain not just a username (subject) but also a bundle of attributes that can further serve to identify the user, define a users’ roles, or be otherwise consumed by the service. In addition, the assertion does capture the notion of what entity is “issueing” the assertion (asserting the user identity). Lastly, some SOA stacks may not be able to handle a username token with no password.

So after all that, what is the bearer confirmation good for? Given that it allows us to utilize assertions without the hassles and costs that come with the signing and key references that are a part of the other confirmation methods, bearer is the perfect confirmation method for basic identity propagation to or between internal services. A similar use case where bearer may fit the bill is identity propagation from trusted intermediary that maybe be doing the real authentication to the service over a securely established network connection.

Even the Longest Journey Starts with the Smallest Step - OpenAz

With this simple post to the XACML TC message list, it begins.

OpenAz is an effort to build a new standard open source API for authorization. The initial version of the API is based on XACML. Think of it as a standard way of interfacing with a XACML engine using Java. Now, XACML as a policy language definitely has its challenges - I dare a human being to author a meaningful policy in XACML - but the simple runtime model - a few objects - all based on attributes is pretty nice and flexible, and this is something worth building on.

I think we also have to honest and say that the existing Java standard authorization APIs - checkPermission and its JEE cousin JSR 115 - are not great general purpose authorization APIs. They are very tightly bound into the Java code level security. This is good when you're trying to protected Java applets from downloading malicious code, but presents some challenges in other contexts. On the plus side, the Java permissions API is totally standard and available - on all platforms, so you can reliably write to it - it been around for a long time.

There has been some thinking on converging the Java Permission and XACML models previously, but this is not explicitly the goal of Open Az. OpenAz ambitiously looks define a new ubiquitous standard that both PEP and PDP vendors can use to integrate against. My first foray into the OpenAz API will be on the PDP side...I'm looking to build a reference implementation of a PDP, but my true interest in this is on the PEP side. I hope that OpenAz will be the ultimate answer to Where have all the PEPs gone?

This one is definitely going to be a marathon, not a sprint, but I think that with both Oracle and Cisco making initial contributions, there is some strong industry interest which should hopefully spur adoption and consequently innovation. As always, I'm open to your suggestions, and it is open source, so feel free to get your hands dirty and help out.

WS-Policy and My Dog Lily

This is my dog, Lily. Besides being and adorable puppie-wuppie, she was born blind. Yet here is a picture of her swimming in a lake. I wish I had video of her...she will swim out and fetch the ball. I'm not kidding. She is amazing. So how does she do it? Well, as it turns out "sighted" dogs have lousy sight. Dogs actually have a really good sense of smell, and hearing, and Lily uses some combination of these find the ball.

WS-Policy, despite what people make think, does not necessarily make interoperability of web-services any easier. Practical interoperability is actually achieved at the WS-Security level - through the exchange of messages. WS-Policy as a standard does not prescribe what the corresponding message looks like. It just says "this message is going to be encrypted with Basic 256". We can all agree that there are lots of ways that SOAP message could look...WS-Security gives us a lot of help here, but as you wade through the various pieces of WS-Security specification, and get into things like Derived and Encrypted Keys, there are a lot of inferences that are left to be made between the WS-Policy and the SOAP message.

I'm not on a crusade against WS-Policy, but I've run into a number of customers in the past few weeks that have gotten hung up on WS-Policy and in particular OSB's inability in the current release to consume WS-Policy on a WSDL. This is just a "Blind Dog"...OSB has rich WS-Security capabilities and can work with many of those end points even if it doesn't understand the assertions. Why? Because OSB supports WS-Security 1.0, SAML 1.1, Transport Level Security with SSL...and these capabilities are broadly interoperable with a number of Web Service vendors and implementations.

The key is that OSB, and WLS and OWSM for that matter, all have the ability to define a policy to be used on the client. It does not have to come from the WS-Policy attached to the WSDL. The "trick" is that you may have to simply remove the offending WS-Policy statements from the WSDL - and save it locally - to get client side stubs to get design time tooling - OSB pipeline or JAX-WS/RPC client stubs.

This does require some understanding of what the server's WS-Policy is trying to say...that is what does it expect....version of WS-Security, Is it signed, Is it encrypted, what tokens are included? Fortunately, WLS, OSB and OWSM all include pre-built client side policies that include some best practices and common scenarios, so that in most cases, you won't have to start from scratch, or modify the client policies at all. You just need to know which one to pick...pretty straight forward, assuming that you know something about the WS-Policy and what it means. If your expectation is that WS-Policy will just magically make security happen, then I think that we as an industry are a long way away from that Nirvana.

I work with many customers that have WS-Policy implementations that both "sides" understand, but still the messages don't work. There is no substitute for testing....that is vendor-to-vendor industry interoperability testing. Vendors continue to invest in this, but in the mean time, if you're going to use WS-Policy you'll need to understand how it works at some level. Remember, SSL or some other transport level security is always a reasonable choice. It meets many SOA security use cases.