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 (http://www.jboss.org/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 (http://www.jboss.org/picketlink/AuthZ.html) and
> the authorization part in Seam3 Security
> (http://www.seamframework.org/Seam3/SecurityModuleOverview) 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.
Willem
|