WebSphere Application Server 7.0.0.7 and JAXB performance improvements

As Andrew Spyker posted here, the 7.0.0.7 improvements to JAXB will help both JAX-RS and JAX-WS services when enabled.  These were enabled via tighter integration with our XML parser shipped in WebSphere Application Server.

The larger your payloads, the more benefit the user should see.  Let us know how it works out for you?

Which Identity is used for Authorization

In one of my recent discussions, I came across a question on which identity is used for authorization checks in WebSphere for SOAP over HTTP web services.   For the background of web services authorization in a JEE server, please read our previous blog entry (Web Services and Authorization).

Is it the transport level identity or instead the message level identity (assuming the identity is propagated using WS-Security)? The answer is it depends.

1. If the web service is implemented as a Java Bean and hosted in a Web container, then the security model is based on the JEE servlet/JSP security model. The JEE role based authorization check is URL based.
   
   Underneath the covers, the Web container intercepts the HTTP request, authenticates the identity from the HTTP transport and performs the authorization check. The message level security is not processed yet, as the Web container does not understand or process the SOAP message.
   
   The transport level identity is used in this case for roles defined in the JEE deployment descriptors.
   
   But if you are using the programming API (e.g. WebServiceContext.isUserInRole) to performs authorization checks in JAX-RPC/ JAX-WS application handlers or web services provider implementation, then it could be either the transport level identity or message security identity. But the message level identity always overrides the transport level identity in security context since message level security is processed after transport level security.
   
   
2. If the web service is implemented as stateless EJB, then the identity could be either the transport level identity or message security identity.   The message level identity always overrides the transport level identity in the security context since message level security is processed after transport level security.  This applies to both roles defined in the JEE deployment descriptors and programmatic APIs authorization check.
   
   The reason is that the web service EJB is leveraging the Web container to handle the HTTP protocol. In this case, the authorization is done by the Web container (Router Servlet) and the EJB container. The identity in message level security in the SOAP message is processed and set in the security context before calling the EJB container.  Therefore, either HTTP transport level identity or message level security identity could be used.
   
   In this scenario, you can use JEE role based method level authorization to protect the web services.

I hope this helps to clarify which identity is used for web service authorization check.

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.

Demonstration of the SAML Token support in v7.0.0.7

I spent some time over the weekend recording a demo of a scenario which shows how to use our SAML support that shipped as part of v7.0.0.7 and was introduced on this blog last week.  The demonstration walks through a simple application, attaches some SAML-specific policy sets, and walks through a little of the configuration of the Policy Sets themselves.   A key takeaway is showing that nothing changes from an application programming model perspective.  All of the work is done by an administrator (and can be easily reused by other applications.  The demo is <10 minutes long, and is located here.

Hopefully, this will visually help others conceptualize how they will use this in their own environment.

Apache Wink 1.0 in WebSphere Application Server

I'm glad to see that Apache Wink has reached it's 1.0 status and can be officially downloaded.   As I've seen various people deploy Apache Wink to WebSphere, I've had to point out a few things that are (and are not needed) when deploying the Wink libraries to WebSphere.  I've made a short video which showcases some of these items.

However, for brevity sake, some of the basic items are listed as follows:

• WebSphere Application Server v7.0 (and the Feature Pack for Web Services on v6.1) both include JAXB, StAX, and the Java Activation Framework libraries (so the support can be obtained from WebSphere)
• slf4j-jdk14 should be used instead of slf4j-simple.  This will enable better integration of the emitted informational/trace/debug messages.
• File Serving needs to be disabled in the ibm-web-ext.xml file (if a user wants to use a URL mapping of "/*"
• Shared libraries currently work either attached to the Web Application or at the Application level with a classloader setting of Application.  A known JIRA is open to resolve a classloading issue for classloaders set to Module and attached at the Application level.

I hope this helps some folks get started using Apache Wink on WebSphere...

SAML for Web Services is now available with WebSphere 7.0.0.7

You probably have read the announcement letter on the XML Feature Pack, SCA Refresh, and SAML (Security Assertion Markup Language) for Web Services support coming to WebSphere 7.0.

I would like to give some additional details of what is in the SAML support.

1. Supports scenarios targeting OASIS Web Services Security SAML Token Profile 1.1
1. Supports SAML Token Assertion specifications v1.1 and v2.0
2. Supports Bearer confirmation and Holder-of-key confirmation
2. Configurable via policy sets
1. Targets JAX-WS services
2. Leverages Custom Token Support
3. API to create and consume SAML assertions
1. Allows customers to create SSO solutions independent from web services
4. Issuing Token
1. Supports an external STS (Security Token Service)
1. Tested with Tivoli Federated Identity Manager
2. API supports request and validation of SAML Assertions via standard WS-Trust v1.2 and v1.3 Protocols
2. Supports sender (client) side SAML token caching for better performance
3. Supports self-issuance

It is now available, so try it out and feel free to give us some feedback on your experiences.

P.S. Here is the SAML support Info Center link.