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.