Thursday, August 27, 2009

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.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.