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.

Configuring WLS 10.3 and OSB for "old school" SOA Security

In SOA, the propagation of identity is not limited to end-users. Identifying and tracking which application or service is invoking a service is just as important. In many cases, SLAs are by organization or application not by user. This is not to say that the user is unimportant, but that both the identity of the application and the identity of the user has their role in a typical SOA.

A common example is to have a service bus (OSB) fronting a collection of back-end services. The bus is interested in the application's identity and in entrusted to enforce authorization polices at the proxy service level - This application is authorized to call the viewCustomer service. The service that the request is routed to (the business service) is very interested in the actual user for audit purposes and finer grained authorization - User "X" can see those particular customers. Therefore it is essential for the web-service consumer to call the service passing both the application and the user identity.

Many good choices here, but I want to focus on the details of one solution in particular - SAML Token Profile using Sender-Vouches subject confirmation method. As the name implies, the sender - in this case the application - vouches for the subject - the user authenticated to the application. The application signs the message which contains a SAML Assertion with the user as the subject. The message is received by OSB, the SAML Assertion is validated and the identity of the user is established as the Subject. Before you close your browser - this is not another How to debug SAML post. There are some interesting nuances to this use-case.

• How to get WLS to invoke a OSB service given that OSB and WLS 10.3 use different versions of WS-Policy?
• How to get the message signed by the right "application", given that the PKI CredMapper only gets passed the user and the target service, not the application?
• How to get OSB to do authorization based on the application's identity (message signer), not the SAML subject, yet make sure that when OSB calls the business service, that it uses the user's and not the application's identity?

I spent nearly an entire plane flight from Boston to San Francisco discussing the possibilities here, but this is the solution that I like:

• JAX-RPC can be configured simply with a custom policy. This is basically a local file that the contains the client's policy. This is an alternative to retrieving the WS-Policy from the WSDL. Getting this set-up with JAX-WS is a little trickier, but also doable. Gerard Davidson's Blog has a nice example.
• Next, short of writing a custom credential mapper (I promise I will post how), a nice simplifying assumption is that the application is the managed server or better the identity of the managed server. Configure all of the managed server's to use the same alias in a keystore with the same relative path (from domain root). This allows the PKI credmapper to map all users (some common group that all users are in like "customers") to the alias of the server. All SOAP requests out of the server will use the server identity. You can restrict this by specifying destination hosts/ports/URL etc if needed. Also, its worth noting that if you wanted to do this at the transport level, you could just enable the "Use Server Cert" check box on the SSL tab of the managed server.
• Finally, I think, the key to doing authorization inside of OSB based on the identity of the application is to have the application appear in the JAAS Subject as a group. I think its simpler to do this from the calling application by using either a custom Authenticator to add the application name as a group or a NameMapper to add it to the SAML Assertion directly. Either way, when the assertion appears at OSB, the application name can easily be retrieved and placed in the JAAS Subject, which result in a group, which can be used for authorization inside of OSB.

This approach puts more of a burden on the client (configured with policy and passing the application name in the assertion), but I think it represents a very good use of the out-of-the-box capabilities of both WLS and OSB with little customization.

I'd be interested in hearing other people's ideas on how to solve this issue...maybe using 2-way SSL or UserNameTokens instead of SAML.

So that's what WebLogic Certificate Registry is for...

<11/08/2009 12h10min32s ACT> <Error> <> <BEA-000000> <CertPathBuilder does not support building cert path from class weblogic.security.pk.SubjectKeyIdentifierSelector
java.security.InvalidAlgorithmParameterException: [Security:090596]The WebLogicCertPathProvider was passed an unsupported CertPathSelector.
at weblogic.security.providers.pk.WebLogicCertPathProviderRuntimeImpl$JDKCertPathBuilder.engineBuild(WebLogicCertPathProviderRuntimeImpl.java:682)



In a previous post I talked a little bit about how the WebLogic Sercurity Framework can be extended to support OCSP and CRL checking. Besides being used in SSL validation, the CertificationProviders are used in validating signatures in web services messages. When a response is received, it is typically signed. The way that the certificate that signed the response is identified is through a <wsee:SecurityTokenReference> This refernce can be of several types - SubjectKeyIdentifier, IssuerSerialNumber, Thumbprint#SHA1. You can use use what is called a direct-reference, which is to say the actual certificate itself is passed in the message.

Assuming that you don't want to pass the certificate itself (they're big), and you're passing one of the referenced tokens back to WebLogic Server, how should it find it? CLV = Certificate Lookup and Validation. In the OCSP/CRL check post, we focused more on the validation part of the CertificationProvider. Here, we're interested in lookup. The OOTB CertificationProvider which essentially wraps the JDK's provider only supports direct references (X509). In order to support more other references, like say SubjectKeyIdentifier, you need to configure the a CertificateRegistry provider. You add the list of certificates from the WLS admin console, and now the signature on the response can be validated.

Basically, if you're using WS-Security, then you need to configure a CertificateRegistry.