We chatted a bit via voice but wanted to follow up on list for benefit of all...
On Wednesday 30 March 2011 3:14:07 AM Anubhav Sharma wrote: > Hi Dan, > > Sorry for the late reply, was caught up in fixing some Blocker issues. > Thanks for your changes!! Really appreciate your efforts on this. > > I am not sure about point 7. Shouldn't it be the responsibility of the STS > implementation to authenticate the incoming usernameToken? In such a case, > users can implement authentication the way they want in the IssueOperation > implementation. Yes, but in a different way. If you have WSS4J properly configured and the WS-SecPol properly defines the requirement of the UsernameToken, then WSS4J will do the username token processing and authentication. If the authentication fails, WSS4J will fail immedately and a generic "security error" fault would get sent back immediately. The actual STS implementation code would never get called. It's more of a "fail fast" scenario. > Yes, some of the stuff should be moved to examples, the IssueOperation > implementation, it should not be part of the framework impl. I will do > that. OK. Perfect. I definitely had trouble figuring out what should be "example" and what should be framework. > I would make the CRLVerifier not to be dependent on the bouncycastle > classes, would be better this way. However it should be a part of the > example implementation so wont be a big deal. Right. If it's part of the example, Maven can pull it in, no problem. Thanks! Dan > > Thanks and Cheers, > Anubhav > > > > On 3/25/11 8:01 PM, "Daniel Kulp" <[email protected]> wrote: > > On Thursday 24 March 2011 11:17:16 AM Anubhav Sharma w > > rote: > > Hi Dan, > > > > I have attached a new version of the STS Provider impl to the Jira issue. > > It contains some defect fixes we found in the sample Issue implementation > > during our testing. Thanks for your suggestion regarding the response > > marshalling, I have incorporated it in the new version. Would be nice if > > you can have a look again. > > Definitely a step in the right direction. I want to start getting this > integrated into the builds, but it's not *quite* ready. What I've done is > cloned the cxf repo on github and taken you patch and started integrating > it into the build. See: > > https://github.com/dkulp/cxf/ > > I've also added you as a contributor so it would be good if you can start > working with me on that copy there to get it ready to push it onto trunk at > Apache. > > A list of major changes I made: > > 1) It's all part of rt/ws/security now which is likely where it should be. > > 2) I modified the code generation to generate everything in org.apache.cxf > namespaces which is where we would need it. I also just code generate the > schemas. I had some issues with the mapping when generating from the wsdl. > There's a bug in the code generator someplace relating to the ws-addressing > mapping we do. I haven't had time to figure out what the bug is. Doesn't > realy matter for this though. > > 3) Updated the STS provider/impl to throw an unsupported operation soap > fault for operations that are not configured in. I definitely prefer > only configuring in the stuff you want/need and have a good exception > thrown for the others. > > 4) Removed all the *Delegate things from the operations package. They > aren't really needed with (3). > > 5) Cleaned up the dispatching in the Provider so you can write an operation > that implements multple interfaces and have it dispatch correctly. It > also handles the requestCollection case that doesn't take the same > parameters as the other operations. > > 6) I've added the WebServiceContext to all the operation methods. This is > important as you may need the results of the WSS4J processing or the basic > auth principal or other. > > 7) I REMOVED the PasswordCallbackHandler thing you had and the > authentication stuff you were doing in IssuedOperationDelegate. The way > it was being used was definitely not thread safe. Plus, with WSS4J 1.6, > the authorization is being handled by it. By the time it gets into the > STS, the username token will be valid and authenticated already. (that > assume the WS-SecurityPolicy for the STS is properly defined) I then get > the UsernameToken from the context for the name. > > > My main question at this point has to do with the intentions. I pretty > much took your entire "src" tree and moved into rt/ws/security. I wasn't > sure if some of it is really the "framework" that should be there and > possibly some of it should be just part of an example. The stuff for the > tomcat-users that was in there was obviously just example stuff, but with > the removal of the UsernameToken stuff, it's no longer there anyway. > Thus, it could probably remain as is. > > The other concern I have is the CRLVerifier depending directly on > bouncycastle classes. Not a huge deal, but that does then make > bouncycastle a stronger requirement for using the STS. > > In anycase, if you could start helping me out in my cxf repo clone at > github, that would be great. I definitely think its getting close. > > Dan > > > Thanks and Cheers, > > Anubhav > > > > > > > > On 3/11/11 8:11 PM, "Daniel Kulp" <[email protected]> wrote: > > > > On Friday 11 March 2011 11:26:56 AM Anubhav Sharma wrote: > > > Hi Dan, > > > > > > Thanks for your inputs. I have cleaned up the code and attached a new > > > version of the STS provider to the JIRA issue. I have incorporated your > > > inputs regarding DOMSource and JAXB, you are right, it is much simpler > > > that way. I still need to check for the code generation issue. > > > > Definitely looking a lot better. The response part could still use > > some work. Instead of doing a DOMSource, you could do: > > > > RequestSecurityTokenResponseCollectionType tokenResponse = > > > > (RequestSecurityTokenResponseCollectionType) > > > > methods[x] > > > > .invoke(operationImpl, rst); > > > > if (tokenResponse == null) { > > > > throw new Exception("Error in implementation > > > > class."); } > > > > return new JAXBSource(jaxbContext, > > > > new ObjectFactory() > > > > .createRequestSecurityTokenResponseCollection(tokenResponse)); > > > > There are two advantages: > > 1) The QName on the element is correct. :-) > > 2) Completely avoids the DOM creation. CXF can directly write the > > JAXBSource out from the events it would generate. > > > > Dan > > > > > Thanks and Cheers, > > > Anubhav > > > > > > On 3/9/11 3:42 AM, "Daniel Kulp" <[email protected]> wrote: > > > > > > > > > > > > This is definitely a good start. As you said, the code needs some > > > major cleanup which does make it a bit harder to really review. > > > > > > My initial 2-minute thoughts: > > > > > > Code generation issues: > > > 1) We really need to generate the code into org.apache.cxf namespace > > > someplace. A jaxb binding file would take care of that. > > > > > > 2) Also, do we really need to generate for things like the xmldsig and > > > policy namespaces? Seems a bit strange to me. > > > > > > > > > Runtime: > > > The provider is marked PAYLOAD and DOMSource. Thus, the DOM just > > > contains the contents of the SOAP Body. However, the first thing you > > > do is convert to a SOAPMessage. Why? I don't see the point in that > > > and I think it's wrong as the envelop and body wouldn't be there. > > > > > > I'd recommend switching to just Source (instead of DOMSource). You can > > > then return a JAXBSource object and eliminate the entire JAXB -> DOM > > > step in there. It's a little trickier on the incoming side, but not by > > > a lot. Most likely, I would just take the original incoming Source and > > > feed it directly into JAXB to unmarshal, and then grab the RequestType > > > out of the JAXB object. (or from the ws-a Action header that could be > > > injected in via the WebServiceContext). > > > > > > Anyway, definitely a good start. > > > > > > Dan > > > > > > On Tuesday 08 March 2011 10:05:19 AM Anubhav Sharma wrote: > > > > Hi All, > > > > > > > > I have attached an initial implementation of the STS provider > > > > framework and the Issue operation. The eclipse project is attached > > > > to the following Jira: > > > > https://issues.apache.org/jira/browse/CXF-1940 > > > > > > > > I still need to refractor the code with regards to logging, exception > > > > tracing, checkstyles etc. I would request you all to provide an > > > > initial feedback while I proceed with the code cleanup. > > > > > > > > Thanks! > > > > Anubhav > > > > > > > > > > > > On 2/23/11 1:46 PM, "Anubhav Sharma" <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > Hello Everyone, > > > > > > > > I would like to contribute an STS provider framework to the CXF > > > > project. The idea would be to implement a provider based STS service, > > > > the obvious reason being that it can support both WS Trust 1.3 and > > > > 1.4 versions. The invoke method of this provider would convert the > > > > request into > > > > corresponding JAXB objects and delegate the call to the right > > > > implementation. The implementation of operations like Issue, Renew > > > > etc. would be configured in spring. The users would just need to > > > > implement their business logic for these operations and configure > > > > the > > > > implementation class in spring. > > > > > > > > As an example I would also like to contribute a sample implementation > > > > for the Issue operation. This sample would accept UsernameToken and > > > > X509Token as inputs, use local file system for authentication and > > > > return back a SAML Token. I would propose to support both, SAML 1.1 > > > > and SAML 2.0. In the RST, user can use TokenType attribute to request > > > > either a SAML 1.1 or 2.0 token. > > > > > > > > This would give the CXF users an opportunity to use and test the sts > > > > client against the sample STS implementation, extend the STS with > > > > their business implementations and in future we can enhance STS with > > > > a more sophisticated and complete implementation. > > > > > > > > Would appreciate your views and inputs on this. > > > > > > > > Cheers, > > > > Anubhav > > > > > > -- > > > Daniel Kulp > > > [email protected] > > > http://dankulp.com/blog > > > Talend - http://www.talend.com > > > > -- > > Daniel Kulp > > [email protected] > > http://dankulp.com/blog > > Talend - http://www.talend.com > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
