Hi, The changes look good - Arrays no problem. I will wait for the maven snapshot to come down and clean up my code. I don't use SimplePrincipal myself. The Spring Framework UsernamePasswordAuthenticationToken class implements principal and I am using spring security for authentication so I just stick that token in as the first token. I just erase the credentials before putting back into the subject.
For now I only have the time and need for Username password. In a couple of months I will be looking at x.509 certs so might have a look then. Do you know what the expected release date of 2.3.1 is? Whats the normal dev cycle? On Mon, Nov 8, 2010 at 10:14 PM, Sergey Beryozkin <[email protected]> wrote: > 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. >> >> >> > >> >
