Hi Oliver, >> 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.
What I meant is that the Sharepoint web services (which is company-wide installation, not so easy to play around with) are currently also using HTTP-based Authentication using the same Negotiation mechanism. In the CXF Client configuration we put 'Negotiate' as AuthorizationType. If we can't disable this (due to company policy reasons) we won't be able to actually send the HTTP POST with the SOAP message of the web service request. >> I've deployed the CXF STS with Kerberos once in delegate mode but the STS >> was only validating a "delegated" kerberos ticket. It was the responsibility >> of the client to request a new ticket on behalf of the original ticket from >> the KDC but this was out of my control. I don't think it will be a problem for us to get a new ticket for the original ticket. We're quite familiar with SPNEGO and the GSS API so it should just be a question of getting it from the KDC from the original ticket, which will presumably be in the HTTP request. What I can't figure out is how to make CXF use it when we're at the point of making an outgoing web service call to Sharepoint. So if STS can help in this regard it would be great. Thanks again for your help! Best regards, Josef -----Original Message----- From: Oliver Wulff [mailto:owu...@talend.com] Sent: 17 July 2012 23:04 To: users@cxf.apache.org Subject: RE: Kerberos authentication using delegation from Principal Ticket >>> - 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) >>> It's the same for the browser. The user performs GET to your application, the application redirects to ADFS, reply with 401 negotiate, if ticket valid, ADFS issues a SAML token and add role information or other information. The SAML token is posted from the browser to your tomcat application. The Saml token is validated and security context with roles from saml token is created (genericprincipal in tomcat). No need for JNDIRealm - Roles can be checked with security constraints in web.xml or isUserInRole() >>> - Will the web application still get the Principal with AD Groups as Roles as it does now? (currently through JNDIRealm) >>> Yes, see above. You can even request other so called claims from ADFS like firstname, lastname, email, etc. to be added to the SAML token. >>> - 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. >>> Sharepoint services must be configured for SAML (usually just configure WIF in Sharepoint, Windows Identity Foundation). We used WIF in some ASP.NET applications as well. I'd say Microsoft is/was leading the WS-Federation implementation as WIF is there for some years and CXF Fediz supports the same for Java for some months. >>> 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. >>> Sorry, I don't understand your question. >>> 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? >>> I've deployed the CXF STS with Kerberos once in delegate mode but the STS was only validating a "delegated" kerberos ticket. It was the responsibility of the client to request a new ticket on behalf of the original ticket from the KDC but this was out of my control. 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 22:44 To: users@cxf.apache.org Subject: RE: Kerberos authentication using delegation from Principal Ticket 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 ________________________________ Josef Bajada Senior Technical Architect GO GO, Fra Diegu Street, Marsa, MRS 1501. t +356 2594 6826 ________________________________
