Hi Jason thanks for experimenting with the new code, there's a chance some signatures and even packages might change before 2.3.1 as it is still a work in progress but hopefully we won't do many more changes...
See more comments inline... On Fri, Nov 5, 2010 at 10:58 PM, Jason Pell <[email protected]> wrote: > Hi, > > To test your approach I overrode the > protected SecurityContext createSecurityContext(final Principal p, > final Subject subject) { > > in my interceptor that extends AbstractUsernameTokenInInterceptor > > @Override > protected SecurityContext createSecurityContext(final Principal p, > final Subject subject) { > List<Principal> principals = new > ArrayList<Principal>(subject.getPrincipals()); > > Principal principal = > principals.size() > 0 && !(principals.get(0) > instanceof Group) ? > (Principal) principals.get(0) : p; > > return new DefaultSecurityContext(principal, subject); > } > > Works very nicely. In my createSubject method I actually insert the > Authentication class as the first principal and now I can get access > to this class in the WebServiceContext getUserPrincipal() method. > > Would be great to see this code added to the > AbstractSecurityContextInInterceptor > > I committed some changes yesterday : http://svn.apache.org/viewvc?rev=1032296&view=rev The only difference I used set.toArray(T[] array), hope you're ok with that :-). By default, a (1st) principal associated with Subject will be used in the SecurityContext, but the original Principal (created by WSS4J) can easily be chosen by overriding a newly introduced AbstractSecurityContextInterceptor.getPrincipal. This default selection will probably make sense in most cases. While I was committing that change, I thought that in case of UsernameTokens, a (CXF) UsernameToken has all the information for concrete subclasses of AbstractSecurityContextInterceptor/AbstractUsernameTokenInterceptor to easily (re)create a Principal, when creating a Subject. CXF even ships a SimplePrincipal helper which can be used in simple cases. What I'm not sure about is how it will work with more complex tokens. Basically, I'm thinking that may be AbstractSecurityContextInterceptor.createSubject(SecurityToken token) should be changed to AbstractSecurityContextInterceptor.createSubject(SecurityToken token, Principal originalPrincipal) ? I don't quite like this change, given that in case of UsernameTokens "Principal originalPrincipal", but may be in case of more complex tokens it would not be easy to 'recreate' a Principal ? So having this 2nd parameter will just let subclasses to ensure Subject has all the right Groups added in but just add the original Principal as a Subject identity ? Not sure, may be I'm just over-complicating things a bit. If we could have one more token added, certificates or binary based, then we'd clearly see what else needs to be updated. If you have cases where other tokens can be used then it would be good if you could try the new approach with those tokens as well...May be David V or Glen can help as well... Thoughts ? 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. > >> > > >
