cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Wulff <owu...@talend.com>
Subject RE: Kerberos authentication using delegation from Principal Ticket
Date Tue, 17 Jul 2012 21:03:37 GMT
>>>
- 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.Bajada@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:owulff@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.Bajada@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
________________________________

Mime
View raw message