Hi Oliver, Thanks a lot for your prompt response!
Well given that we managed to get Kerberos working we were hoping to get the Principal ticket delegated in some way, because at the moment all requests to Sharepoint are being done with the web-app's account rather than the logged User principal. This is a very small (but important) part of a much larger application which just needs to have users authenticate quickly without re-entering their username/password to do their work. A lot of functionality based on the Principal and its Roles (based on Active Directory groups) is already in place too. If we enable the Fediz plugin in Tomcat: - Will the authentication handshake be the same from a browser point of view? (User performs GET request for a secure page, SPNEGO replies with 401 Negotiate, browser replies with Kerberos ticket which carries the username, which can then be used with JNDIRealm) - Will the web application still get the Principal with AD Groups as Roles as it does now? (currently through JNDIRealm) - Does WS-Federation require any special configuration on the Sharepoint side? From experience MS tends to be a bit of a laggard in implementing these OASIS standards which are typically not commonly supported. Any way to use normal HTTP Kerberos Authentication too with the framework you are suggesting? I think we would still need to do this to get the payload through. Having a look at STS, it seems to support KerberosToken. Maybe there is a way to use STS to get a new Ticket for the container-provided Principal, but for the remote web-service? Thanks and regards, Josef -----Original Message----- From: Oliver Wulff [mailto:owu...@talend.com] Sent: 17 July 2012 22:04 To: users@cxf.apache.org Subject: RE: Kerberos authentication using delegation from Principal Ticket Hi Josef I make quite a lof of experience with kerberos and the "delegate" mechanism of it which turned out to be very tricky. Kerberos works fine within Microsoft as administration is very easy. All resources (client, servers) are managed by an AD domain/kerberos realm but it's much more difficult to get it running across different platforms like Microsoft and Java - especially debugging is very tricky. Therefore, I'd like to propose an easier approach. WS-Federation is supported by Microsoft ADFS as well as SAML in SharePoint. ADFS supports Kerberos for your browser clients thus the user doesn't have to enter username/password if the computer is in the same AD domain (kerberos realm). For Tomcat, you can configure the CXF Fediz plugin. This plugin will redirect unauthenticated requests to ADFS - your identity provider (IDP). ADFS authenticates browser clients using kerberos or whatever you configured in ADFS. The authentication mechanism has no impact on your Tomcat application. The Fediz plugin validates SAML tokens issued by ADFS. You can then use this SAML token to request a new token (actas) from ADFS for the sharepoint service. Kerberos only occurs between the browser and ADFS (which is your Identity Provider). You can also add additional information from AD into the SAML token (ex. roles) You can find more information about CXF Fediz here: http://cxf.apache.org/fediz.html The example you describe matches with the fediz example "wsclientWebapp" which is described here: http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/README.txt?view=markup The design of the example is described here: http://owulff.blogspot.ch/2012/04/sso-across-web-applications-and-web.html Let me know what you think. Thanks Oli ------ Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com ________________________________________ From: Josef Bajada [josef.baj...@go.com.mt] Sent: 17 July 2012 20:56 To: users@cxf.apache.org Subject: Kerberos authentication using delegation from Principal Ticket 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? 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. 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, 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. ________________________________ Josef Bajada Senior Technical Architect GO GO, Fra Diegu Street, Marsa, MRS 1501. t +356 2594 6826 ________________________________
