Hi,
I think that sounds ok. My experience is that often the final
principal will differ from the original which is why ldap has a user
dn search attribute to find the actual user principal based on the
initial one.
Also while I have your attention. I was confused as to why the
changes to WSS4JInInterceptor for ws-security.ut.no-callbacks do not
support direct configuration of the interceptor (I noted this perhaps
incorrectly on the CXF-3063 patch).
I updated locally to be:
//boolean utWithCallbacks =
// !MessageUtils.getContextualBoolean(msg,
SecurityConstants.USERNAME_TOKEN_NO_CALLBACKS, false);
// allows it to be set from a spring bean interceptor or jaxws:property
boolean utWithCallbacks =
!MessageUtils.isTrue(getProperty(msg,
SecurityConstants.USERNAME_TOKEN_NO_CALLBACKS));
Which allowed me to create an interceptor like so:
<bean id="WSS4JInInterceptor"
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
<constructor-arg>
<map>
<entry key="action" value="UsernameToken" />
<entry key="passwordType" value="PasswordText"
/>
<entry key="ws-security.ut.no-callbacks"
value="true" />
</map>
</constructor-arg>
</bean>
Would love to know if this change can be formalised before 2.3.1 is released.
By the way, love the abstraction of the WSS4J from the rest of the
authorisation very neat
Thanks
Jason
On Sat, Nov 6, 2010 at 5:22 AM, Sergey Beryozkin <[email protected]> wrote:
>
> Hi
>
> On Fri, Nov 5, 2010 at 2:21 PM, Jason Pell <[email protected]> wrote:
>
> > Hi,
> >
> > I am struggling with configuring CXF and spring security. I am running the
> > 2.3.1-SNAPSHOT which has some improvements to the WSS4JInInterceptor. So
> > basically what I have is a JAX-WS service using ws-security to authenticate
> > using username password token. The username is the uid= of the DN of a
> > user
> > record in LDAP.
> >
> > What I want is for the Principal saved into teh CXF SecurityContext to have
> > the Full DN of the user.
> >
> > So what I have setup by way of interceptors are:
> >
> > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
> > (ws-security.ut.no-callbacks = true)
> > I have a custom class which extends
> > org.apache.cxf.interceptor.security.AbstractUsernameTokenInInterceptor to
> > use spring security to create the Subject. I am creating a subject with
> > the
> > full DN of the user.
> >
> > However the
> > org.apache.cxf.interceptor.security.AbstractSecurityContextInInterceptor
> > ignores this and recreates the SecurityContext with the original username
> >
> > SecurityContext sc = createSecurityContext(context.getUserPrincipal(),
> > subject);
> >
> >
> the assumption was that the Principal created by WSS4J initially does
> represent the final/correct Principal.
> So may be the interceptor should be updated like this :
>
> List<?> principals = subject.getPrincipals();
>
> Principal p = principals.size() > 0 && !(principals.get(0) instanceof Group)
>
> ? (Principal)principals.get(0) :
> context.getUserPrincipal();
>
> SecurityContext sc = createSecurityContext(p, subject);
>
> something like that...
>
> What do you think ?
>
> cheers, Sergey
>
>
> So I am kind of up the creek without any kind of paddle :-)
> >
> > Any suggestions for how I might proceed. I guess I can always create my
> > own
> > interceptor from scratch to do this. I already did the same thing to
> > populate the full DN of groups.
> >
