You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jason Pell <ja...@pellcorp.com> on 2010/12/17 00:19:10 UTC

Re: Authentication in cxf and getting the full DN into the Principal

Hi,

Thought I should post an update.  Now that I have a little more
experience I have realised I can set a jaxws:property directly on a
JaxWsServerFactoryBean like so:


		JaxWsServerFactoryBean serverFactory = new JaxWsServerFactoryBean();
		Map<String, Object> properties = new HashMap<String, Object>();
		properties.put("ws-security.ut.no-callbacks", "true");
		serverFactory.setProperties(properties);

I have now deleted my hack.

Might be helpful for someone else trying to use this directly.  Bit of
a D'oh moment for me actually :-)

On Mon, Nov 8, 2010 at 10:20 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
>
> On Fri, Nov 5, 2010 at 9:48 PM, Jason Pell <ja...@pellcorp.com> 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 <sb...@gmail.com>
>> wrote:
>> >
>> > Hi
>> >
>> > On Fri, Nov 5, 2010 at 2:21 PM, Jason Pell <ja...@pellcorp.com> 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.
>> > >
>>
>