Hi On Fri, Nov 5, 2010 at 9:48 PM, Jason Pell <[email protected]> wrote:
> Hi, > > ... > 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. > > I started working on this issue after it was reported that extending WSS4JInInterceptor does not work in wsdl/policy-first cases, where no explicit configuration of WSS4JInInterceptor is done. Thus I had to go with the contextual properties approach... May be we can just combine two boolean checks ? > By the way, love the abstraction of the WSS4J from the rest of the > authorisation very neat > > thanks Sergey > 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. > > > >
