Sounds good to me. Colm.
On Thu, May 5, 2011 at 12:03 PM, Sergey Beryozkin <[email protected]> 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/org.apache.cxf.common.security keeps SimpleGroup > and SimplePrincipal helpers for creating custom > javax.security.auth.Subjects. 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/org.apache.cxf.interceptor.security 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 >
