Geplaatst op 17 November 2009, 22:48 door Jeroen Benckhuijsen in java, soa, open source, integratie, architectuur, security

For regular users of this blog: in contrast with other posts this one is in English as it is cross linked to the MuleSoft blog (http://blog.mulesoft.org/) and community (http://www.mulesoft.org/display/COMMUNITY/Home) on this subject. I apologize for the inconvenience.

When you're using services to develop and integrate applications in an enterprise, security is of course one of the major issues which need to be addressed. The deployed services often allow access to core functionality in your enterprise ranging from financial and human-resource systems to the core mission critical systems. In a SOA where communication is based on Web Services, we often see two options for ensuring security, which may be combined:

1. Web Services communication is handled over a secure connection using SSL (i.e. using HTTPS).
   
   
2. The WS-Security standard, which is used to handle security at the SOAP level.
   
   

The advantage of the first approach is the (relative) simplicity with which connections can be secured using just a configuration of your favourite web server. For authentication you have to use solutions like HTTP basic authentication or use  client-side certificates. The latter of course introduces the need for quite a lot of administration. Finally, the main disadvantage of using this scheme is the need to reimplement security when switching protocols (e.g. when you decide to use SOAP over JMS in case you need reliable messaging and dislike the WS-Reliable Messagingstandard).

Using WS-Security alleviates you from this burden. Security is handled at the SOAP level and is agnostic of the actual transport protocol used. Also, access to the authentication information is often quite easier from Web Service frameworks in comparison with using HTTPS. WS-Security supports various profiles - defining the way the security information is passed - of which the Username Token profile is the most widely used. The U/T profile sends an (optionally hashed) password along with a user-name to the service, which may use this information for authentication purposes.

This approach works fine for a lot of scenarios involving system to system communication, however it lacks a few features:

1. No easy way to deal with different identity stores in which users are stored, perhaps having multiple user-names and/or passwords
   
   
2. No easy way to centralize management of security
   
   
3. No easy way to create a single-sign on among services or handle pre-authenticated clients
   
   

The SAML specification and it's accompanying profile for WS-Security tries to solve these issues, and allows for two use-cases depending on the trust relations in your enterprise: Sender Vouches and Holder of Key. Also, SAML allows for some simple authorization statements, although that may be better handled using XACML.

In reality, SAML isn't often used to create a security infrastructure. Two reasons for this may be the complexities of the specification itself and the few amount of quite mature SOA implementations having a need for federated identity management which SAML offers. Commercial vendors often offer implementations, however the various Open Source integration projects are often either lacking SAML support, or it hasn't been well tested.

One of the Open Source projects which has recently gained support for SAML is the Open Source ESB Mule ESB. This is achieved through the SAML module, which lately had it's first release. The original module was devised for a project within Atos Origin, used for a presentation on the annual JFall conference (in Dutch) and Open Sourced to the Mule community.

Now, the code has been cleaned, documentation has been added and it has been tested to be used in the wild. Initial support is mainly focused on the Sender Vouches use case, support for Holder of Key is still preliminary. For Mule, this is seen as a major addition. On the MuleSoft websites, a Podcast, blog post and a press release can be found describing this first release of the module.

After this first release, attention is first of all focused on getting a clean set of documentation explaining the various use cases and the way they can be implemented using this module. Also, getting Holder of Key support is of course also a major issue. Afterwards, plans exist to extend the module to support more "enterprisy" features, like using LDAP as a storage for keys, and perhaps even support for XACML to handle more complex authorization use cases.

For now, I hope people will find this module useful. The intention is to make SAML easier to use and allow usage of Open Source integration products in scenarios which would often require commercial product. Any issues can of course be communicated using the bug tracking tools or mailing lists of the project.




Share this | 684 keer bekeken | 0 reacties