Hi Sergey, I was thinking along your lines, only a bit differently, not sure if it makes sense (would appreciate your comments).
After some more research I think that I could implement the HttpAuthSupplier, say MyDelegateAuthSupplier and specify it as the authSupplier within the conduit in the spring configuration of my jaxws:client I am thinking that what I would do then inside this MyDelegateAuthSupplier is get the HttpServletRequest from Spring (I don't think I would have a WebServiceContext at the authSupplier right?) using AuthWiring or using the old RequestContextHolder. >From there I think I could get the Authorization HTTP header to get the SPNEGO >Header, which I am hoping I could use to get another Ticket to access the >remote service using GSS. Does my line of thought make sense? Thanks, Josef -----Original Message----- From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] Sent: 18 July 2012 00:34 To: users@cxf.apache.org Cc: Josef Bajada Subject: Re: Kerberos authentication using delegation from Principal Ticket Hi Josef, Oli On 17/07/12 19:56, Josef Bajada wrote: > Hi, > > I have a situation where Single Sign On using Kerberos (with Microsoft AD) is > being used (Tomcat 7, SPNEGO, JNDIRealm). > All works fine and the user authenticates automatically with Tomcat and the > Principal for that user is obtained which the web application can use. > > The Web Application needs to consume a web-service (Sharepoint) on behalf of > the user. CXF is being used as the Web Service client to consume this web > service. I presume that what needs to be done (I might be wrong) is that a > new Kerberos ticket for the User Principal needs to be obtained which > correspond with the account of the remote web service (Sharepoint). > > How, do I go about configuring the setup to have CXF pass a ticket which > corresponds to the remote service (rather than the web app's account) for the > authenticated User? > > I suppose that some kind of credential delegation needs to be in place > (possibly we need to do some GSS code ourselves?), and in some way the CXF > Client needs to be informed about which ticket to include in the headers? The credential delegation was enabled by default in SpnegoAuthSupplier, and now this property is configurable (as per recommendation in the original code). > > I also had a good look at these: > http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29 > > http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html > > But they seem to be referring to a fixed Principal where either the username > is configured directly in spring, or the principal is specified in login.conf. > I need to use the Principal dynamically provided through Tomcat, depending on > who is logged in. > The original Principal available on the incoming chain will not be available in the outbound chain for a CXF client code to pick up. So some mechanism for passing the Principal needs to be set up. I guess the simplest case is to get a principal name from the injected context (WebServiceContext in JAX-WS cases) or obtain it from HttpServletRequest, etc. Next a CXF Client's HTTPConduit needs to get AuthorizationPolicy populated exactly as demoed on the wiki, before the call is made. I've just added an outbound interceptor too but for the moment it is stuck in the jaxrs frontend. So something like this should do (for JAXWS): Client client = ClientProxy.getClient(soapClient); HTTPConduit http = (HTTPConduit)client.getConduit(); AuthorizationPolicy policy = new AuthorizationPolicy(); policy.setAuthorizationType(HttpAuthHeader.AUTH_TYPE_NEGOTIATE); policy.setAuthorization("KerberosClient"); //jaas context name policy.setUserName(getTomcatPrincipalName()); http.setAuthorization(policy); soapClient.doIt(); This will probably work fine. Sergey > My environment is as follows: > Java 1.7.0_04 > Apache Tomcat 7.0.29 > Apache CXF 2.6.1 > Spring Framework 3.1.2.RELEASE > > Thanks for your help. > > Josef > > > Josef Bajada > Senior Technical Architect > GO > > GO, Fra Diegu Street, Marsa, MRS 1501. > t +356 2594 6826 > w www.go.com.mt<http://www.go.com.mt> > > This email and any files or content transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. This message contains confidential information and is intended > only for the individual named. If you are not the named addressee you should > not disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. If you are not the intended recipient you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. The > Company and the originator of this email accept no liability for the content > of this email, or for the consequences of any actions taken on the basis of > the information provided, unless that information is subsequently confirmed > in writing. If you are not the intended recipient you are notified that > disclosing, copying, di stributing or taking any action in reliance on the contents of this information is strictly prohibited. > > Warning: Although the Company and the originator have taken reasonable > precautions to ensure no viruses are present in this email, the company > cannot accept responsibility for any loss or damage arising from the use of > this email or attachments. > ________________________________ > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com Josef Bajada Senior Technical Architect GO GO, Fra Diegu Street, Marsa, MRS 1501. t +356 2594 6826 ________________________________
