The ZEN of SOA - Lessons Learned and an Executive Blueprint


Tuesday, October 10, 2006
Working on our encryption service that is deployed on an appliance. Bluedog's lead developer has come up with a nifty hash plug-in. The question remains, how difficult is it to enable others to use the service?



As we know, web services, and SOA in particular, represents an approach to distributed software that provides an abstraction that exposes business functionality as abstracted services that are both location independent and discoverable, possibly even on the intenet. Two considerations to application security should be considered. Primarily, the identity mechanism and policies might vary among legacy or back-office systems. Users might have different passwords and privileges for each system, so when users access a composite service, they may still need to be authenticated to each back-end system. Of course, Single Sign On is meant to address this.

Also, because the service layer acts as a mask of the details of the underlying technology implementation from the users, each service abstracts the user identity context as well. Connecting the particular users to overall functionality can be problematic, as SOA itself provides no overall security context. That is why we emphasize architecting with security (and single-sign-on) in mind.