cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject rt/security module
Date Thu, 05 May 2011 11:03:10 GMT
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

Mime
View raw message