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. ________________________________
