On Monday 08 November 2010 7:50:10 am Jason Pell wrote: > 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?
I'm thinking the end of Nov or first week in Dec. Normally, it's about every 8 weeks. However, with 2.3.0 being a ".0", I'm likely to shorten it a couple weeks just to get the ".1" out there. I've had several people not look at 2.3.0 just cause of the ".0". I think next time we'll skip 2.4.0 and go straight to 2.4.1. :-) Dan > 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.AbstractUsernameTokenInIntercepto > >> >> r > >> > >> 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.AbstractSecurityContextInIntercep > >> >> tor 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. -- Daniel Kulp [email protected] http://dankulp.com/blog
