camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: Camel security
Date Fri, 02 Apr 2010 07:58:01 GMT
jliu wrote:
> Claus Ibsen-2 wrote:
>> Its important that we do this in a manner so the security framework of
>> choice can easily be plugged in, as many have different needs.
>> And some are forced to use JAAS etc.
>> So it should NOT be a Spring Security that master how we do this in Camel. 
> +1.
>  Ideally the Camel security will be pluggable, so that ppl can plug
> different security implementations into Camel. For example, for Drools
> project, I may want to use Picketlink ( as
> the underlying authentication and authorization implementation. Other people
> may prefer Spring security or their own implementations.
> If we dig into technical details a little bit, I believe the authentication
> part should be straightforward. As long as JAAS is used, different
> authentication implementations can always be plugged in easily. The headache
> part is the authorization. There is no standard we can use in this area, and
> I am not sure how easy it is to write a framework that can plug in different
> authorization implementations. For example, it may not be possible to write
> an authorization framework that is flexible enough to switch its underlying
> impl among Picketlink Authz ( and
> the authorization part in Seam3 Security
> ( and the
> authorization part in Spring security. Mostly likely Camel will have to come
> out with its own specific authorization implementation or just choose an
> existing one. 

The reason that I choice Spring Security to implement the authorization 
mechanism supports different kinds of AccessDecisionVoter, and they are 
spring friendly.

In Spring Security, the authorization will be delegate to the 
AccessDecisionManager and you can setup different AccessDecisionVoter on 
it, maybe we can add a layer in Camel to plug the different 
authorization implementation.


View raw message