Hi Sergey, Yes the Principal will be available (i.e. the Username).
I am thinking that we will need to generate the new token for the remote service (Sharepoint) from the original Token we had received from the browser. So we would need to do gsscontext.getDelegCr() to get the Delegate Credentials for the user and get the new token from that, so that we put it in the outbound HTTP header. As far as I know (again I could be mistaken), the old ticket would be only valid for our URL (SPN), and a new one would be needed for the Sharepoint URL. Thanks a lot, Josef -----Original Message----- From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] Sent: 18 July 2012 00:49 To: Josef Bajada Cc: users@cxf.apache.org Subject: Re: Kerberos authentication using delegation from Principal Ticket Hi On 17/07/12 23:41, Josef Bajada wrote: > 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. > What I do not understand is what exactly is needed for the propagation to succeed. I thought that the Principal representing the original user and obtained via a Kerberos login early at the Tomcat level was already available. Or do you actually need to manually process the Negotiate value ? Cheers, Sergey > 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-suppor >> t.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthenticat >> ion%28Kerberos%29 >> >> http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/s >> un/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, d i > 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 > ________________________________ 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, distributing 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. ________________________________
