Web Services and Authorization

I've gotten involved in some discussions with customers asking questions about web services and authorization. In an attempt to clear up some of the ambiguities, I decided to start with going back to the basics and stating to customers what is the intended capabilities of the technology so that they can see for themselves a bit of what is the magic. The initial problem that some customers have is understanding how authorization works for Java EE-based web services.

Some of the facts are:

• There is a security model for both Web Resources and EJB resources. Both support role based authorization to control access to resources
• Web Resources are URIs and the methods on Web Resources are GET, PUT, POST, and DELETE
• EJBs are objects/services and the methods/operations on EJB resources are more RPC-level methods
• You can secure/authorize both types of resources appropriately...

Now, that said, let's add in "SOAP-based Web Services". To a great extent, this starts to blend the 2 models... (in the usage of HTTP as your transport)...

• JAX-RPC and JAX-WS represent programming models for SOAP-based Web Services.
• JAX-RPC defined a mapping model, as well as an unmanaged "client" programming model. There is no standard "deployment" model for exposing Web Services in JAX-RPC.
• JSR 109 adds to that a "management" model, where you can now define "declaratively" Web Services to be exposed. In addition, you can now manage service references (clients) to those resources.
• WebSphere uses JSR 109 metadata (i.e. service name or service reference name) in order to attach qualities of service to those resources
• JAX-WS get's a *little* better in this space (since annotations can be used to denote service references - and clients) - which is why we are able to use a notion like "policy sets" to attach resources to the "attachment-points" defined by annotated classes...

Lastly, this brings us to the matter at hand - authorization....

• There is one small fly in the ointment mapping SOAP-based HTTP-centric Web Services, and that is all services are issued over a POST.
• For services hosted as EJBs, "users" can be identified and secured using standard HTTP-transport mechanisms (or Message-level mechanisms), and the authorization of methods can be handled via the normal authorization checks for method/operation level security in EJBs.
• For services hosted as POJOs in a Web Container, since it's all a POST, *all* you can do is validate (if anything at all) that the user is a valid user (with the standard J2EE level mechanisms for security).
• You *could* invent your own authorization logic to check (at the application-level) what role the caller is in, etc... (under the various operations) - but, that's essentially doing the same as what is built-for-you with using EJBs.
• Lastly, there is nothing preventing you from doing this by delegating the request to an EJB container. The additional cost of the container breach is roughly what you are paying for (performance-wise).

Hopefully, this will help clear up whatever confusion users have with how authorization and web services works.