Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Oliver Wulff <owulff@talend.com>
To: "users@cxf.apache.org" <users@cxf.apache.org>
Subject: RE: Kerberos authentication using delegation from Principal Ticket
Thread-Topic: Kerberos authentication using delegation from Principal Ticket
Thread-Index: Ac1kS4h44JXCMO4vTqaiWnn52jzUKwABw3MnAAGjwrAAATHscw==
Date: Tue, 17 Jul 2012 21:03:37 +0000
Message-ID: <79AB4452999C844D9920E0363533273119D916@S10BE002.SH10.lan>
References: <029F19A0A3828F409E2F145593359C0E0BE40E@MSEMBox1.corporate.intra>
 <79AB4452999C844D9920E0363533273119D802@S10BE002.SH10.lan>,<029F19A0A3828F409E2F145593359C0E0BE459@MSEMBox1.corporate.intra>
In-Reply-To: <029F19A0A3828F409E2F145593359C0E0BE459@MSEMBox1.corporate.intra>
Accept-Language: en-GB, de-DE, en-US
Content-Language: en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>>>=0A=
- Will the authentication handshake be the same from a browser point of vie=
w? (User performs GET request for a secure page, SPNEGO replies with 401 Ne=
gotiate, browser replies with Kerberos ticket which carries the username, w=
hich can then be used with JNDIRealm)=0A=
>>>=0A=
It's the same for the browser. The user performs GET to your application, t=
he application redirects to ADFS, reply with 401 negotiate, if ticket valid=
, ADFS issues a SAML token and add role information or other information. T=
he SAML token is posted from the browser to your tomcat application. The Sa=
ml token is validated and security context with roles from saml token is cr=
eated (genericprincipal in tomcat). No need for JNDIRealm - Roles can be ch=
ecked with security constraints in web.xml or isUserInRole()=0A=
=0A=
>>>=0A=
- Will the web application still get the Principal with AD Groups as Roles =
as it does now? (currently through JNDIRealm)=0A=
>>>=0A=
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.=0A=
=0A=
>>>=0A=
- Does WS-Federation require any special configuration on the Sharepoint si=
de? From experience MS tends to be a bit of a laggard in implementing these=
 OASIS standards which are typically not commonly supported. =0A=
>>>=0A=
Sharepoint services must be configured for SAML (usually just configure WIF=
 in Sharepoint, Windows Identity Foundation). We used WIF in some ASP.NET a=
pplications as well.=0A=
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 mon=
ths.=0A=
=0A=
>>>=0A=
Any way to use normal HTTP Kerberos Authentication too with the framework y=
ou are suggesting? I think we would still need to do this to get the payloa=
d through.=0A=
>>>=0A=
Sorry, I don't understand your question.=0A=
=0A=
=0A=
>>>=0A=
Having a look at STS, it seems to support KerberosToken. Maybe there is a w=
ay to use STS to get a new Ticket for the container-provided Principal, but=
 for the remote web-service?=0A=
>>>=0A=
I've deployed the CXF STS with Kerberos once in delegate mode but the STS w=
as only validating a "delegated" kerberos ticket. It was the responsibility=
 of the client to request a new ticket on behalf of the original ticket fro=
m the KDC but this was out of my control.=0A=
=0A=
Thanks=0A=
Oli=0A=
=0A=
=0A=
------=0A=
=0A=
Oliver Wulff=0A=
=0A=
Blog: http://owulff.blogspot.com=0A=
Solution Architect=0A=
http://coders.talend.com=0A=
=0A=
Talend Application Integration Division http://www.talend.com=0A=
=0A=
________________________________________=0A=
From: Josef Bajada [Josef.Bajada@go.com.mt]=0A=
Sent: 17 July 2012 22:44=0A=
To: users@cxf.apache.org=0A=
Subject: RE: Kerberos authentication using delegation from Principal Ticket=
=0A=
=0A=
Hi Oliver,=0A=
=0A=
Thanks a lot for your prompt response!=0A=
=0A=
Well given that we managed to get Kerberos working we were hoping to get th=
e Principal ticket delegated in some way, because at the moment all request=
s to Sharepoint are being done with the web-app's account rather than the l=
ogged User principal. This is a very small (but important) part of a much l=
arger application which just needs to have users authenticate quickly witho=
ut re-entering their username/password to do their work. A lot of functiona=
lity based on the Principal and its Roles (based on Active Directory groups=
) is already in place too.=0A=
=0A=
If we enable the Fediz plugin in Tomcat:=0A=
- Will the authentication handshake be the same from a browser point of vie=
w? (User performs GET request for a secure page, SPNEGO replies with 401 Ne=
gotiate, browser replies with Kerberos ticket which carries the username, w=
hich can then be used with JNDIRealm)=0A=
=0A=
- Will the web application still get the Principal with AD Groups as Roles =
as it does now? (currently through JNDIRealm)=0A=
=0A=
- Does WS-Federation require any special configuration on the Sharepoint si=
de? 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 suggest=
ing? I think we would still need to do this to get the payload through.=0A=
=0A=
Having a look at STS, it seems to support KerberosToken. Maybe there is a w=
ay to use STS to get a new Ticket for the container-provided Principal, but=
 for the remote web-service?=0A=
=0A=
Thanks and regards,=0A=
=0A=
Josef=0A=
=0A=
=0A=
-----Original Message-----=0A=
From: Oliver Wulff [mailto:owulff@talend.com]=0A=
Sent: 17 July 2012 22:04=0A=
To: users@cxf.apache.org=0A=
Subject: RE: Kerberos authentication using delegation from Principal Ticket=
=0A=
=0A=
Hi Josef=0A=
=0A=
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 Micro=
soft as administration is very easy. All resources (client, servers) are ma=
naged by an AD domain/kerberos realm but it's much more difficult to get it=
 running across different platforms like Microsoft and Java - especially de=
bugging is very tricky. Therefore, I'd like to propose an easier approach.=
=0A=
=0A=
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 (kerbe=
ros realm).=0A=
=0A=
For Tomcat, you can configure the CXF Fediz plugin. This plugin will redire=
ct unauthenticated requests to ADFS - your identity provider (IDP). ADFS au=
thenticates browser clients using kerberos or whatever you configured in AD=
FS. The authentication mechanism has no impact on your Tomcat application. =
The Fediz plugin validates SAML tokens issued by ADFS. You can then use thi=
s SAML token to request a new token (actas) from ADFS for the sharepoint se=
rvice. Kerberos only occurs between the browser and ADFS (which is your Ide=
ntity Provider). You can also add additional information from AD into the S=
AML token (ex. roles)=0A=
=0A=
You can find more information about CXF Fediz here:=0A=
http://cxf.apache.org/fediz.html=0A=
=0A=
The example you describe matches with the fediz example "wsclientWebapp" wh=
ich is described here:=0A=
http://svn.apache.org/viewvc/cxf/fediz/trunk/examples/wsclientWebapp/README=
.txt?view=3Dmarkup=0A=
=0A=
The design of the example is described here:=0A=
http://owulff.blogspot.ch/2012/04/sso-across-web-applications-and-web.html=
=0A=
=0A=
Let me know what you think.=0A=
=0A=
Thanks=0A=
Oli=0A=
=0A=
=0A=
------=0A=
=0A=
Oliver Wulff=0A=
=0A=
Blog: http://owulff.blogspot.com=0A=
Solution Architect=0A=
http://coders.talend.com=0A=
=0A=
Talend Application Integration Division http://www.talend.com=0A=
=0A=
________________________________________=0A=
From: Josef Bajada [Josef.Bajada@go.com.mt]=0A=
Sent: 17 July 2012 20:56=0A=
To: users@cxf.apache.org=0A=
Subject: Kerberos authentication using delegation from Principal Ticket=0A=
=0A=
Hi,=0A=
=0A=
I have a situation where Single Sign On using Kerberos (with Microsoft AD) =
is being used (Tomcat 7, SPNEGO, JNDIRealm).=0A=
All works fine and the user authenticates automatically with Tomcat and the=
 Principal for that user is obtained which the web application can use.=0A=
=0A=
The Web Application needs to consume a web-service (Sharepoint) on behalf o=
f 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 corr=
espond with the account of the remote web service (Sharepoint).=0A=
=0A=
How, do I go about configuring the setup to have CXF pass a ticket which co=
rresponds to the remote service (rather than the web app's account) for the=
 authenticated User?=0A=
=0A=
I suppose that some kind of credential delegation needs to be in place (pos=
sibly we need to do some GSS code ourselves?), and in some way the CXF Clie=
nt needs to be informed about which ticket to include in the headers?=0A=
=0A=
I also had a good look at these:=0A=
http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html=
#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerber=
os%29=0A=
=0A=
http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/sun/sec=
urity/auth/module/Krb5LoginModule.html=0A=
=0A=
But they seem to be referring to a fixed Principal where either the usernam=
e is configured directly in spring, or the principal is specified in login.=
conf.=0A=
I need to use the Principal dynamically provided through Tomcat, depending =
on who is logged in.=0A=
=0A=
My environment is as follows:=0A=
Java 1.7.0_04=0A=
Apache Tomcat 7.0.29=0A=
Apache CXF 2.6.1=0A=
Spring Framework 3.1.2.RELEASE=0A=
=0A=
Thanks for your help.=0A=
=0A=
Josef=0A=
=0A=
=0A=
Josef Bajada=0A=
Senior Technical Architect=0A=
GO=0A=
=0A=
GO, Fra Diegu Street, Marsa, MRS 1501.=0A=
t   +356 2594 6826=0A=
w www.go.com.mt<http://www.go.com.mt>=0A=
=0A=
This email and any files or content transmitted with it are confidential an=
d intended solely for the use of the individual or entity to whom they are =
addressed. This message contains confidential information and is intended o=
nly 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 delet=
e this e-mail from your system. If you are not the intended recipient you a=
re notified that disclosing, copying, distributing or taking any action in =
reliance on the contents of this information is strictly prohibited. The Co=
mpany 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 confirme=
d in writing. If you are not the intended recipient you are notified that d=
isclosing, copying, distributing or taking any action in reliance on the co=
ntents of this information is strictly prohibited.=0A=
=0A=
Warning: Although the Company and the originator  have taken reasonable pre=
cautions 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.=0A=
________________________________=0A=
=0A=
Josef Bajada=0A=
Senior Technical Architect=0A=
GO=0A=
=0A=
GO, Fra Diegu Street, Marsa, MRS 1501.=0A=
t   +356 2594 6826=0A=
________________________________=0A=