cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: rt/security module
Date Fri, 06 May 2011 14:00:03 GMT
Sounds good to me.


On Thu, May 5, 2011 at 12:03 PM, Sergey Beryozkin <> wrote:
> Hi
> I've been thinking about introducing a rt/security module which will
> have common security-related classes from
> common/security and rt/core/.../interceptors/security added to it initially.
> cxf-common-utilities/ keeps SimpleGroup
> and SimplePrincipal helpers for creating custom
> It also keeps token beans (UT only)
> which can be used by JAX-WS endpoint interceptors to avoid dealing
> with WSS4J specific tokens (as well for simplifying dealing with the
> custom authorization in policy first cases).
> rt-core/ keeps a couple of default
> SecurityContext implementations, interceptors for simplifying dealing
> with JAAS and using UT tokens for creating custom Subjects, as well as
> for enforcing RBAC authorization rules.
> The reason I'm actually thinking about adding another module which
> keep various common security related helpers in one place is due to
> incoming work to do with supporting SAML authorization.
> Perhaps one obvious place where the relevant code may go is
> rt/ws/security but I do like to have JAX-RS endpoints be able to rely
> on SecurityContext supporting Claims. I'm fine with reusing STSClient
> whenever feasible in context of JAX-RS invocations (basic auth
> validation or retrieving SAML/etc tokens on the client side and then
> finding the way to pass them through without SOAP env). But I think
> the code to do with parsing SAML tokens and creating
> ClaimSecurityContext should be common for both JAX-WS and JAX-RS
> endpoints be able to rely upon it given that JAX-RS endpoints.
> We can have that shared code added to rt/core but I'm not entirely
> sure it will be good in the longer run.
> Thoughts ?
> Sergey

View raw message