Quantcast

Kerberos authentication using delegation from Principal Ticket

classic Classic list List threaded Threaded
28 messages Options
12
jbx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Kerberos authentication using delegation from Principal Ticket

jbx
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.
________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

Oliver Wulff-2
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 [[hidden email]]
Sent: 17 July 2012 20:56
To: [hidden email]
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.
________________________________
jbx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

jbx
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:[hidden email]]
Sent: 17 July 2012 22:04
To: [hidden email]
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 [[hidden email]]
Sent: 17 July 2012 20:56
To: [hidden email]
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
________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

Oliver Wulff-2
>>>
- 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 [[hidden email]]
Sent: 17 July 2012 22:44
To: [hidden email]
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:[hidden email]]
Sent: 17 July 2012 22:04
To: [hidden email]
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 [[hidden email]]
Sent: 17 July 2012 20:56
To: [hidden email]
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
________________________________
jbx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

jbx
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:[hidden email]]
Sent: 17 July 2012 23:04
To: [hidden email]
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 [[hidden email]]
Sent: 17 July 2012 22:44
To: [hidden email]
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:[hidden email]]
Sent: 17 July 2012 22:04
To: [hidden email]
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 [[hidden email]]
Sent: 17 July 2012 20:56
To: [hidden email]
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
________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
In reply to this post by jbx
Hi Josef, Oli


On 17/07/12 19:56, Josef Bajada wrote:

> 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?

The credential delegation was enabled by default in SpnegoAuthSupplier,
and now this property is configurable (as per recommendation in the
original code).

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

The original Principal available on the incoming chain will not be
available in the outbound chain for a CXF client code to pick up.

So some mechanism for passing the Principal needs to be set up.
I guess the simplest case is to get a principal name from the injected
context (WebServiceContext in JAX-WS cases) or obtain it from
HttpServletRequest, etc.

Next a CXF Client's HTTPConduit needs to get AuthorizationPolicy
populated exactly as demoed on the wiki, before the call is made.

I've just added an outbound interceptor too but for the moment it is
stuck in the jaxrs frontend.

So something like this should do (for JAXWS):

Client client = ClientProxy.getClient(soapClient);
HTTPConduit http = (HTTPConduit)client.getConduit();

AuthorizationPolicy policy = new AuthorizationPolicy();
policy.setAuthorizationType(HttpAuthHeader.AUTH_TYPE_NEGOTIATE);
policy.setAuthorization("KerberosClient"); //jaas context name
policy.setUserName(getTomcatPrincipalName());

http.setAuthorization(policy);

soapClient.doIt();

This will probably work fine.

Sergey

> 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, d
 i
stributing 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.
> ________________________________
>


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com
jbx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

jbx
Hi Sergey,

I was thinking along your lines, only a bit differently, not sure if it makes sense (would appreciate your comments).

After some more research I think that I could implement the HttpAuthSupplier, say MyDelegateAuthSupplier and specify it as the authSupplier within the conduit in the spring configuration of my jaxws:client

I am thinking that what I would do then inside this MyDelegateAuthSupplier is get the HttpServletRequest from Spring (I don't think I would have a WebServiceContext at the authSupplier right?) using AuthWiring or using  the old RequestContextHolder.

From there I think I could get the Authorization HTTP header to get the SPNEGO Header, which I am hoping I could use to get another Ticket to access the remote service using GSS.

Does my line of thought make sense?

Thanks,

Josef


-----Original Message-----
From: Sergey Beryozkin [mailto:[hidden email]]
Sent: 18 July 2012 00:34
To: [hidden email]
Cc: Josef Bajada
Subject: Re: Kerberos authentication using delegation from Principal Ticket

Hi Josef, Oli


On 17/07/12 19:56, Josef Bajada wrote:

> 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?

The credential delegation was enabled by default in SpnegoAuthSupplier, and now this property is configurable (as per recommendation in the original code).

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

The original Principal available on the incoming chain will not be
available in the outbound chain for a CXF client code to pick up.

So some mechanism for passing the Principal needs to be set up.
I guess the simplest case is to get a principal name from the injected
context (WebServiceContext in JAX-WS cases) or obtain it from
HttpServletRequest, etc.

Next a CXF Client's HTTPConduit needs to get AuthorizationPolicy
populated exactly as demoed on the wiki, before the call is made.

I've just added an outbound interceptor too but for the moment it is
stuck in the jaxrs frontend.

So something like this should do (for JAXWS):

Client client = ClientProxy.getClient(soapClient);
HTTPConduit http = (HTTPConduit)client.getConduit();

AuthorizationPolicy policy = new AuthorizationPolicy();
policy.setAuthorizationType(HttpAuthHeader.AUTH_TYPE_NEGOTIATE);
policy.setAuthorization("KerberosClient"); //jaas context name
policy.setUserName(getTomcatPrincipalName());

http.setAuthorization(policy);

soapClient.doIt();

This will probably work fine.

Sergey

> 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, di
stributing 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.
> ________________________________
>


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Josef Bajada
Senior Technical Architect
GO

GO, Fra Diegu Street, Marsa, MRS 1501.
t   +356 2594 6826
________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
Hi
On 17/07/12 23:41, Josef Bajada wrote:

> Hi Sergey,
>
> I was thinking along your lines, only a bit differently, not sure if it makes sense (would appreciate your comments).
>
> After some more research I think that I could implement the HttpAuthSupplier, say MyDelegateAuthSupplier and specify it as the authSupplier within the conduit in the spring configuration of my jaxws:client
>
> I am thinking that what I would do then inside this MyDelegateAuthSupplier is get the HttpServletRequest from Spring (I don't think I would have a WebServiceContext at the authSupplier right?) using AuthWiring or using  the old RequestContextHolder.
>
>  From there I think I could get the Authorization HTTP header to get the SPNEGO Header, which I am hoping I could use to get another Ticket to access the remote service using GSS.
>
What I do not understand is what exactly is needed for the propagation
to succeed. I thought that the Principal representing the original user
and obtained via a Kerberos login early at the Tomcat level was already
available.

Or do you actually need to manually process the Negotiate value ?

Cheers, Sergey


> Does my line of thought make sense?
>
> Thanks,
>
> Josef
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:[hidden email]]
> Sent: 18 July 2012 00:34
> To: [hidden email]
> Cc: Josef Bajada
> Subject: Re: Kerberos authentication using delegation from Principal Ticket
>
> Hi Josef, Oli
>
>
> On 17/07/12 19:56, Josef Bajada wrote:
>> 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?
>
> The credential delegation was enabled by default in SpnegoAuthSupplier, and now this property is configurable (as per recommendation in the original code).
>
>>
>> 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.
>>
>
> The original Principal available on the incoming chain will not be
> available in the outbound chain for a CXF client code to pick up.
>
> So some mechanism for passing the Principal needs to be set up.
> I guess the simplest case is to get a principal name from the injected
> context (WebServiceContext in JAX-WS cases) or obtain it from
> HttpServletRequest, etc.
>
> Next a CXF Client's HTTPConduit needs to get AuthorizationPolicy
> populated exactly as demoed on the wiki, before the call is made.
>
> I've just added an outbound interceptor too but for the moment it is
> stuck in the jaxrs frontend.
>
> So something like this should do (for JAXWS):
>
> Client client = ClientProxy.getClient(soapClient);
> HTTPConduit http = (HTTPConduit)client.getConduit();
>
> AuthorizationPolicy policy = new AuthorizationPolicy();
> policy.setAuthorizationType(HttpAuthHeader.AUTH_TYPE_NEGOTIATE);
> policy.setAuthorization("KerberosClient"); //jaas context name
> policy.setUserName(getTomcatPrincipalName());
>
> http.setAuthorization(policy);
>
> soapClient.doIt();
>
> This will probably work fine.
>
> Sergey
>
>> 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,
 d
i

> stributing 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.
>> ________________________________
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
> Josef Bajada
> Senior Technical Architect
> GO
>
> GO, Fra Diegu Street, Marsa, MRS 1501.
> t   +356 2594 6826
> ________________________________

jbx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

jbx
Hi Sergey,

Yes the Principal will be available (i.e. the Username).

I am thinking that we will need to generate the new token for the remote service (Sharepoint) from the original Token we had received from the browser. So we would need to do gsscontext.getDelegCr() to get the Delegate Credentials for the user and get the new token from that, so that we put it in the outbound HTTP header.

As far as I know (again I could be mistaken), the old ticket would be only valid for our URL (SPN), and a new one would be needed for the Sharepoint URL.

Thanks a lot,

Josef



-----Original Message-----
From: Sergey Beryozkin [mailto:[hidden email]]
Sent: 18 July 2012 00:49
To: Josef Bajada
Cc: [hidden email]
Subject: Re: Kerberos authentication using delegation from Principal Ticket

Hi
On 17/07/12 23:41, Josef Bajada wrote:

> Hi Sergey,
>
> I was thinking along your lines, only a bit differently, not sure if it makes sense (would appreciate your comments).
>
> After some more research I think that I could implement the
> HttpAuthSupplier, say MyDelegateAuthSupplier and specify it as the
> authSupplier within the conduit in the spring configuration of my
> jaxws:client
>
> I am thinking that what I would do then inside this MyDelegateAuthSupplier is get the HttpServletRequest from Spring (I don't think I would have a WebServiceContext at the authSupplier right?) using AuthWiring or using  the old RequestContextHolder.
>
>  From there I think I could get the Authorization HTTP header to get the SPNEGO Header, which I am hoping I could use to get another Ticket to access the remote service using GSS.
>
What I do not understand is what exactly is needed for the propagation to succeed. I thought that the Principal representing the original user and obtained via a Kerberos login early at the Tomcat level was already available.

Or do you actually need to manually process the Negotiate value ?

Cheers, Sergey


> Does my line of thought make sense?
>
> Thanks,
>
> Josef
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:[hidden email]]
> Sent: 18 July 2012 00:34
> To: [hidden email]
> Cc: Josef Bajada
> Subject: Re: Kerberos authentication using delegation from Principal
> Ticket
>
> Hi Josef, Oli
>
>
> On 17/07/12 19:56, Josef Bajada wrote:
>> 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?
>
> The credential delegation was enabled by default in SpnegoAuthSupplier, and now this property is configurable (as per recommendation in the original code).
>
>>
>> I also had a good look at these:
>> http://cxf.apache.org/docs/client-http-transport-including-ssl-suppor
>> t.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthenticat
>> ion%28Kerberos%29
>>
>> http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/s
>> un/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.
>>
>
> The original Principal available on the incoming chain will not be
> available in the outbound chain for a CXF client code to pick up.
>
> So some mechanism for passing the Principal needs to be set up.
> I guess the simplest case is to get a principal name from the injected
> context (WebServiceContext in JAX-WS cases) or obtain it from
> HttpServletRequest, etc.
>
> Next a CXF Client's HTTPConduit needs to get AuthorizationPolicy
> populated exactly as demoed on the wiki, before the call is made.
>
> I've just added an outbound interceptor too but for the moment it is
> stuck in the jaxrs frontend.
>
> So something like this should do (for JAXWS):
>
> Client client = ClientProxy.getClient(soapClient);
> HTTPConduit http = (HTTPConduit)client.getConduit();
>
> AuthorizationPolicy policy = new AuthorizationPolicy();
> policy.setAuthorizationType(HttpAuthHeader.AUTH_TYPE_NEGOTIATE);
> policy.setAuthorization("KerberosClient"); //jaas context name
> policy.setUserName(getTomcatPrincipalName());
>
> http.setAuthorization(policy);
>
> soapClient.doIt();
>
> This will probably work fine.
>
> Sergey
>
>> 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, d
i

> stributing 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.
>> ________________________________
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
> 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

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.
________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
Hi Josef

On 18/07/12 00:03, Josef Bajada wrote:
> Hi Sergey,
>
> Yes the Principal will be available (i.e. the Username).
>
> I am thinking that we will need to generate the new token for the remote service (Sharepoint) from the original Token we had received from the browser. So we would need to do gsscontext.getDelegCr() to get the Delegate Credentials for the user and get the new token from that, so that we put it in the outbound HTTP header.
>
> As far as I know (again I could be mistaken), the old ticket would be only valid for our URL (SPN), and a new one would be needed for the Sharepoint URL.

That is pretty interesting. I just happen to have spent few days only on
the subject, so hope our security experts can help :-).

I thought that the tickets that can be 'forwarded' if the kdc
configuration allows for that.

But may be not, may be gsscontext.getDelegCr() has to be called.

I think that a case like this has to be managed in a simpler way in CXF,
though probably at the moment the way you suggest is the way to go.

I've just added a jaxrs filter but I can definitely push most of the
code to the CXF in interceptor. This filter currently validates the in
service ticket only plus sets a basic SecurityContext. However it can be
configured to propagate the other useful info for SpnegoAuthSupplier to
reuse when this info is available on the message...

Hope you can make it all work - please share the code when you are done
and we can put some of it at the base CXF level

Cheers, Sergey

>
> Thanks a lot,
>
> Josef
>
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:[hidden email]]
> Sent: 18 July 2012 00:49
> To: Josef Bajada
> Cc: [hidden email]
> Subject: Re: Kerberos authentication using delegation from Principal Ticket
>
> Hi
> On 17/07/12 23:41, Josef Bajada wrote:
>> Hi Sergey,
>>
>> I was thinking along your lines, only a bit differently, not sure if it makes sense (would appreciate your comments).
>>
>> After some more research I think that I could implement the
>> HttpAuthSupplier, say MyDelegateAuthSupplier and specify it as the
>> authSupplier within the conduit in the spring configuration of my
>> jaxws:client
>>
>> I am thinking that what I would do then inside this MyDelegateAuthSupplier is get the HttpServletRequest from Spring (I don't think I would have a WebServiceContext at the authSupplier right?) using AuthWiring or using  the old RequestContextHolder.
>>
>>   From there I think I could get the Authorization HTTP header to get the SPNEGO Header, which I am hoping I could use to get another Ticket to access the remote service using GSS.
>>
> What I do not understand is what exactly is needed for the propagation to succeed. I thought that the Principal representing the original user and obtained via a Kerberos login early at the Tomcat level was already available.
>
> Or do you actually need to manually process the Negotiate value ?
>
> Cheers, Sergey
>
>
>> Does my line of thought make sense?
>>
>> Thanks,
>>
>> Josef
>>
>>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:[hidden email]]
>> Sent: 18 July 2012 00:34
>> To: [hidden email]
>> Cc: Josef Bajada
>> Subject: Re: Kerberos authentication using delegation from Principal
>> Ticket
>>
>> Hi Josef, Oli
>>
>>
>> On 17/07/12 19:56, Josef Bajada wrote:
>>> 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?
>>
>> The credential delegation was enabled by default in SpnegoAuthSupplier, and now this property is configurable (as per recommendation in the original code).
>>
>>>
>>> I also had a good look at these:
>>> http://cxf.apache.org/docs/client-http-transport-including-ssl-suppor
>>> t.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthenticat
>>> ion%28Kerberos%29
>>>
>>> http://docs.oracle.com/javase/7/docs/jre/api/security/jaas/spec/com/s
>>> un/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.
>>>
>>
>> The original Principal available on the incoming chain will not be
>> available in the outbound chain for a CXF client code to pick up.
>>
>> So some mechanism for passing the Principal needs to be set up.
>> I guess the simplest case is to get a principal name from the injected
>> context (WebServiceContext in JAX-WS cases) or obtain it from
>> HttpServletRequest, etc.
>>
>> Next a CXF Client's HTTPConduit needs to get AuthorizationPolicy
>> populated exactly as demoed on the wiki, before the call is made.
>>
>> I've just added an outbound interceptor too but for the moment it is
>> stuck in the jaxrs frontend.
>>
>> So something like this should do (for JAXWS):
>>
>> Client client = ClientProxy.getClient(soapClient);
>> HTTPConduit http = (HTTPConduit)client.getConduit();
>>
>> AuthorizationPolicy policy = new AuthorizationPolicy();
>> policy.setAuthorizationType(HttpAuthHeader.AUTH_TYPE_NEGOTIATE);
>> policy.setAuthorization("KerberosClient"); //jaas context name
>> policy.setUserName(getTomcatPrincipalName());
>>
>> http.setAuthorization(policy);
>>
>> soapClient.doIt();
>>
>> This will probably work fine.
>>
>> Sergey
>>
>>> 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, d
> i
>> stributing 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.
>>> ________________________________
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>>
>> 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
>
> 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, d
 i
stributing 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.
> ________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

cschneider
Hi Sergey and Josef,

in Kerberos there are two kinds of tickets. The Ticket Granting Ticket
(TGT) together with a session key is the one issued for the user after
he authenticates on his machine. This ticket then allows to get a
Service Ticket (ST) for a certain server. This service ticket is
typically then forwarded to the webserver during SPNEGO.

So on the server side we can use the ST to authenticate the user but I
am not sure how we can use it to get a Service Token for the next
server. In standard Kerberos this is not possible as far as I know but
Microsoft has a Kerberos extension that allows this. I am not sure
though if this can be used from Java.

In any case the username alone is obviously not enough to get another
ticket. What may be possible is to establish an authentication context
using subject.doAs after the authentication using the ST. In this
context it may then be possible to get another ST but I am not sure how
this works.

So using an STS or Fediz may be the more solid way to solve this.

Christian

Am 18.07.2012 01:15, schrieb Sergey Beryozkin:

> Hi Josef
>
> On 18/07/12 00:03, Josef Bajada wrote:
>> Hi Sergey,
>>
>> Yes the Principal will be available (i.e. the Username).
>>
>> I am thinking that we will need to generate the new token for the
>> remote service (Sharepoint) from the original Token we had received
>> from the browser. So we would need to do gsscontext.getDelegCr() to
>> get the Delegate Credentials for the user and get the new token from
>> that, so that we put it in the outbound HTTP header.
>>
>> As far as I know (again I could be mistaken), the old ticket would be
>> only valid for our URL (SPN), and a new one would be needed for the
>> Sharepoint URL.
>
> That is pretty interesting. I just happen to have spent few days only
> on the subject, so hope our security experts can help :-).
>
> I thought that the tickets that can be 'forwarded' if the kdc
> configuration allows for that.
>
> But may be not, may be gsscontext.getDelegCr() has to be called.
>
> I think that a case like this has to be managed in a simpler way in
> CXF, though probably at the moment the way you suggest is the way to go.
>
> I've just added a jaxrs filter but I can definitely push most of the
> code to the CXF in interceptor. This filter currently validates the in
> service ticket only plus sets a basic SecurityContext. However it can
> be configured to propagate the other useful info for
> SpnegoAuthSupplier to reuse when this info is available on the message...
>
> Hope you can make it all work - please share the code when you are
> done and we can put some of it at the base CXF level
>
> Cheers, Sergey

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
Hi Christian, All
On 18/07/12 10:06, Christian Schneider wrote:

> Hi Sergey and Josef,
>
> in Kerberos there are two kinds of tickets. The Ticket Granting Ticket
> (TGT) together with a session key is the one issued for the user after
> he authenticates on his machine. This ticket then allows to get a
> Service Ticket (ST) for a certain server. This service ticket is
> typically then forwarded to the webserver during SPNEGO.
>
> So on the server side we can use the ST to authenticate the user but I
> am not sure how we can use it to get a Service Token for the next
> server. In standard Kerberos this is not possible as far as I know but
> Microsoft has a Kerberos extension that allows this. I am not sure
> though if this can be used from Java.
>
> In any case the username alone is obviously not enough to get another
> ticket. What may be possible is to establish an authentication context
> using subject.doAs after the authentication using the ST. In this
> context it may then be possible to get another ST but I am not sure how
> this works.
>
> So using an STS or Fediz may be the more solid way to solve this.
>

The quick test shows that the the server side validator is capable of
getting GSSCredential using GSSContext.getDelegCred() (the method name
is a bit cryptic I have to say :-)) but only if the initiator
(SpnegoAuthSupplier) sets the cred delegation property to true (or I
assume if the relevant login process say at the Tomcat level allows for
it).

Next, SpnegoAuthSupplier needs to check if GSSCredential is already
available on the message and if yes, just pass it to the context
creation call and let the context populate the token, without attempting
to log in again.

The delegated GSSCredential can be set by the code, before a WS/RS
client is invoked again.

I'm going to do few minor updates (at the JAX-RS level first) and then
push them to CXF interceptors, for cases like the one Josef is dealing
with easily handled at WS call level too

Cheers, Sergey

> Christian
>
> Am 18.07.2012 01:15, schrieb Sergey Beryozkin:
>> Hi Josef
>>
>> On 18/07/12 00:03, Josef Bajada wrote:
>>> Hi Sergey,
>>>
>>> Yes the Principal will be available (i.e. the Username).
>>>
>>> I am thinking that we will need to generate the new token for the
>>> remote service (Sharepoint) from the original Token we had received
>>> from the browser. So we would need to do gsscontext.getDelegCr() to
>>> get the Delegate Credentials for the user and get the new token from
>>> that, so that we put it in the outbound HTTP header.
>>>
>>> As far as I know (again I could be mistaken), the old ticket would be
>>> only valid for our URL (SPN), and a new one would be needed for the
>>> Sharepoint URL.
>>
>> That is pretty interesting. I just happen to have spent few days only
>> on the subject, so hope our security experts can help :-).
>>
>> I thought that the tickets that can be 'forwarded' if the kdc
>> configuration allows for that.
>>
>> But may be not, may be gsscontext.getDelegCr() has to be called.
>>
>> I think that a case like this has to be managed in a simpler way in
>> CXF, though probably at the moment the way you suggest is the way to go.
>>
>> I've just added a jaxrs filter but I can definitely push most of the
>> code to the CXF in interceptor. This filter currently validates the in
>> service ticket only plus sets a basic SecurityContext. However it can
>> be configured to propagate the other useful info for
>> SpnegoAuthSupplier to reuse when this info is available on the message...
>>
>> Hope you can make it all work - please share the code when you are
>> done and we can put some of it at the base CXF level
>>
>> Cheers, Sergey
>


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
On 18/07/12 13:05, Sergey Beryozkin wrote:

> Hi Christian, All
> On 18/07/12 10:06, Christian Schneider wrote:
>> Hi Sergey and Josef,
>>
>> in Kerberos there are two kinds of tickets. The Ticket Granting Ticket
>> (TGT) together with a session key is the one issued for the user after
>> he authenticates on his machine. This ticket then allows to get a
>> Service Ticket (ST) for a certain server. This service ticket is
>> typically then forwarded to the webserver during SPNEGO.
>>
>> So on the server side we can use the ST to authenticate the user but I
>> am not sure how we can use it to get a Service Token for the next
>> server. In standard Kerberos this is not possible as far as I know but
>> Microsoft has a Kerberos extension that allows this. I am not sure
>> though if this can be used from Java.
>>
>> In any case the username alone is obviously not enough to get another
>> ticket. What may be possible is to establish an authentication context
>> using subject.doAs after the authentication using the ST. In this
>> context it may then be possible to get another ST but I am not sure how
>> this works.
>>
>> So using an STS or Fediz may be the more solid way to solve this.
>>
>
> The quick test shows that the the server side validator is capable of
> getting GSSCredential using GSSContext.getDelegCred() (the method name
> is a bit cryptic I have to say :-)) but only if the initiator
> (SpnegoAuthSupplier) sets the cred delegation property to true (or I
> assume if the relevant login process say at the Tomcat level allows for
> it).
>
> Next, SpnegoAuthSupplier needs to check if GSSCredential is already
> available on the message and if yes, just pass it to the context
> creation call and let the context populate the token, without attempting
> to log in again.
>
> The delegated GSSCredential can be set by the code, before a WS/RS
> client is invoked again.
>
> I'm going to do few minor updates (at the JAX-RS level first) and then
> push them to CXF interceptors, for cases like the one Josef is dealing
> with easily handled at WS call level too

I've done the updates but I'm going to wait with pushing the server side
negotiate handler code to CXF interceptor. Colm has implemented the
advanced WS-Security level Kerberos support,  but I'm not sure it can be
needed at the CXF WS end without WS-Sec

Josef, in your case, how the endpoint is implemented ? Is CXF involved
at all, except for the need to do the outbound call with CXF ?

Sergey

>> Christian
>>
>> Am 18.07.2012 01:15, schrieb Sergey Beryozkin:
>>> Hi Josef
>>>
>>> On 18/07/12 00:03, Josef Bajada wrote:
>>>> Hi Sergey,
>>>>
>>>> Yes the Principal will be available (i.e. the Username).
>>>>
>>>> I am thinking that we will need to generate the new token for the
>>>> remote service (Sharepoint) from the original Token we had received
>>>> from the browser. So we would need to do gsscontext.getDelegCr() to
>>>> get the Delegate Credentials for the user and get the new token from
>>>> that, so that we put it in the outbound HTTP header.
>>>>
>>>> As far as I know (again I could be mistaken), the old ticket would be
>>>> only valid for our URL (SPN), and a new one would be needed for the
>>>> Sharepoint URL.
>>>
>>> That is pretty interesting. I just happen to have spent few days only
>>> on the subject, so hope our security experts can help :-).
>>>
>>> I thought that the tickets that can be 'forwarded' if the kdc
>>> configuration allows for that.
>>>
>>> But may be not, may be gsscontext.getDelegCr() has to be called.
>>>
>>> I think that a case like this has to be managed in a simpler way in
>>> CXF, though probably at the moment the way you suggest is the way to go.
>>>
>>> I've just added a jaxrs filter but I can definitely push most of the
>>> code to the CXF in interceptor. This filter currently validates the in
>>> service ticket only plus sets a basic SecurityContext. However it can
>>> be configured to propagate the other useful info for
>>> SpnegoAuthSupplier to reuse when this info is available on the
>>> message...
>>>
>>> Hope you can make it all work - please share the code when you are
>>> done and we can put some of it at the base CXF level
>>>
>>> Cheers, Sergey
>>
>
>

jbx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

jbx
Hi Sergey,

In my case the endpoint is a simple <jaxws:client> specified in the Spring app-context and injected to a few Controllers or similar classes.

The only extra thing is that we want to 'impersonate' or 'delegate' the user's credentials so that any call we do from the Web Service client appears as if it is being done by the logged in user (the Tomcat principal of the web app which is in fact the client of the web service).

Josef


-----Original Message-----
From: Sergey Beryozkin [mailto:[hidden email]]
Sent: 18 July 2012 14:33
To: [hidden email]
Subject: Re: Kerberos authentication using delegation from Principal Ticket

On 18/07/12 13:05, Sergey Beryozkin wrote:

> Hi Christian, All
> On 18/07/12 10:06, Christian Schneider wrote:
>> Hi Sergey and Josef,
>>
>> in Kerberos there are two kinds of tickets. The Ticket Granting
>> Ticket
>> (TGT) together with a session key is the one issued for the user
>> after he authenticates on his machine. This ticket then allows to get
>> a Service Ticket (ST) for a certain server. This service ticket is
>> typically then forwarded to the webserver during SPNEGO.
>>
>> So on the server side we can use the ST to authenticate the user but
>> I am not sure how we can use it to get a Service Token for the next
>> server. In standard Kerberos this is not possible as far as I know
>> but Microsoft has a Kerberos extension that allows this. I am not
>> sure though if this can be used from Java.
>>
>> In any case the username alone is obviously not enough to get another
>> ticket. What may be possible is to establish an authentication
>> context using subject.doAs after the authentication using the ST. In
>> this context it may then be possible to get another ST but I am not
>> sure how this works.
>>
>> So using an STS or Fediz may be the more solid way to solve this.
>>
>
> The quick test shows that the the server side validator is capable of
> getting GSSCredential using GSSContext.getDelegCred() (the method name
> is a bit cryptic I have to say :-)) but only if the initiator
> (SpnegoAuthSupplier) sets the cred delegation property to true (or I
> assume if the relevant login process say at the Tomcat level allows
> for it).
>
> Next, SpnegoAuthSupplier needs to check if GSSCredential is already
> available on the message and if yes, just pass it to the context
> creation call and let the context populate the token, without
> attempting to log in again.
>
> The delegated GSSCredential can be set by the code, before a WS/RS
> client is invoked again.
>
> I'm going to do few minor updates (at the JAX-RS level first) and then
> push them to CXF interceptors, for cases like the one Josef is dealing
> with easily handled at WS call level too

I've done the updates but I'm going to wait with pushing the server side negotiate handler code to CXF interceptor. Colm has implemented the advanced WS-Security level Kerberos support,  but I'm not sure it can be needed at the CXF WS end without WS-Sec

Josef, in your case, how the endpoint is implemented ? Is CXF involved at all, except for the need to do the outbound call with CXF ?

Sergey

>> Christian
>>
>> Am 18.07.2012 01:15, schrieb Sergey Beryozkin:
>>> Hi Josef
>>>
>>> On 18/07/12 00:03, Josef Bajada wrote:
>>>> Hi Sergey,
>>>>
>>>> Yes the Principal will be available (i.e. the Username).
>>>>
>>>> I am thinking that we will need to generate the new token for the
>>>> remote service (Sharepoint) from the original Token we had received
>>>> from the browser. So we would need to do gsscontext.getDelegCr() to
>>>> get the Delegate Credentials for the user and get the new token
>>>> from that, so that we put it in the outbound HTTP header.
>>>>
>>>> As far as I know (again I could be mistaken), the old ticket would
>>>> be only valid for our URL (SPN), and a new one would be needed for
>>>> the Sharepoint URL.
>>>
>>> That is pretty interesting. I just happen to have spent few days
>>> only on the subject, so hope our security experts can help :-).
>>>
>>> I thought that the tickets that can be 'forwarded' if the kdc
>>> configuration allows for that.
>>>
>>> But may be not, may be gsscontext.getDelegCr() has to be called.
>>>
>>> I think that a case like this has to be managed in a simpler way in
>>> CXF, though probably at the moment the way you suggest is the way to go.
>>>
>>> I've just added a jaxrs filter but I can definitely push most of the
>>> code to the CXF in interceptor. This filter currently validates the
>>> in service ticket only plus sets a basic SecurityContext. However it
>>> can be configured to propagate the other useful info for
>>> SpnegoAuthSupplier to reuse when this info is available on the
>>> message...
>>>
>>> Hope you can make it all work - please share the code when you are
>>> done and we can put some of it at the base CXF level
>>>
>>> Cheers, Sergey
>>
>
>


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.
________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
Hi Josef
On 18/07/12 15:47, Josef Bajada wrote:
> Hi Sergey,
>
> In my case the endpoint is a simple<jaxws:client>  specified in the Spring app-context and injected to a few Controllers or similar classes.
>
> The only extra thing is that we want to 'impersonate' or 'delegate' the user's credentials so that any call we do from the Web Service client appears as if it is being done by the logged in user (the Tomcat principal of the web app which is in fact the client of the web service).
>
Thanks, that answers my question. Specifically, no CXF is involved to
accept the request, it's only used to make the outbound request.

As I've mentioned in the previous message, a server-side CXF filter is
now available which manages the Negotiate scheme and can be used to make
it pretty easy to propagate the available user credential, provided it
is available, over to the outbound client.
However this filter would be of interest only if CXF also acted as a
receiver of the original request

Cheers, Sergey

> Josef
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:[hidden email]]
> Sent: 18 July 2012 14:33
> To: [hidden email]
> Subject: Re: Kerberos authentication using delegation from Principal Ticket
>
> On 18/07/12 13:05, Sergey Beryozkin wrote:
>> Hi Christian, All
>> On 18/07/12 10:06, Christian Schneider wrote:
>>> Hi Sergey and Josef,
>>>
>>> in Kerberos there are two kinds of tickets. The Ticket Granting
>>> Ticket
>>> (TGT) together with a session key is the one issued for the user
>>> after he authenticates on his machine. This ticket then allows to get
>>> a Service Ticket (ST) for a certain server. This service ticket is
>>> typically then forwarded to the webserver during SPNEGO.
>>>
>>> So on the server side we can use the ST to authenticate the user but
>>> I am not sure how we can use it to get a Service Token for the next
>>> server. In standard Kerberos this is not possible as far as I know
>>> but Microsoft has a Kerberos extension that allows this. I am not
>>> sure though if this can be used from Java.
>>>
>>> In any case the username alone is obviously not enough to get another
>>> ticket. What may be possible is to establish an authentication
>>> context using subject.doAs after the authentication using the ST. In
>>> this context it may then be possible to get another ST but I am not
>>> sure how this works.
>>>
>>> So using an STS or Fediz may be the more solid way to solve this.
>>>
>>
>> The quick test shows that the the server side validator is capable of
>> getting GSSCredential using GSSContext.getDelegCred() (the method name
>> is a bit cryptic I have to say :-)) but only if the initiator
>> (SpnegoAuthSupplier) sets the cred delegation property to true (or I
>> assume if the relevant login process say at the Tomcat level allows
>> for it).
>>
>> Next, SpnegoAuthSupplier needs to check if GSSCredential is already
>> available on the message and if yes, just pass it to the context
>> creation call and let the context populate the token, without
>> attempting to log in again.
>>
>> The delegated GSSCredential can be set by the code, before a WS/RS
>> client is invoked again.
>>
>> I'm going to do few minor updates (at the JAX-RS level first) and then
>> push them to CXF interceptors, for cases like the one Josef is dealing
>> with easily handled at WS call level too
>
> I've done the updates but I'm going to wait with pushing the server side negotiate handler code to CXF interceptor. Colm has implemented the advanced WS-Security level Kerberos support,  but I'm not sure it can be needed at the CXF WS end without WS-Sec
>
> Josef, in your case, how the endpoint is implemented ? Is CXF involved at all, except for the need to do the outbound call with CXF ?
>
> Sergey
>>> Christian
>>>
>>> Am 18.07.2012 01:15, schrieb Sergey Beryozkin:
>>>> Hi Josef
>>>>
>>>> On 18/07/12 00:03, Josef Bajada wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Yes the Principal will be available (i.e. the Username).
>>>>>
>>>>> I am thinking that we will need to generate the new token for the
>>>>> remote service (Sharepoint) from the original Token we had received
>>>>> from the browser. So we would need to do gsscontext.getDelegCr() to
>>>>> get the Delegate Credentials for the user and get the new token
>>>>> from that, so that we put it in the outbound HTTP header.
>>>>>
>>>>> As far as I know (again I could be mistaken), the old ticket would
>>>>> be only valid for our URL (SPN), and a new one would be needed for
>>>>> the Sharepoint URL.
>>>>
>>>> That is pretty interesting. I just happen to have spent few days
>>>> only on the subject, so hope our security experts can help :-).
>>>>
>>>> I thought that the tickets that can be 'forwarded' if the kdc
>>>> configuration allows for that.
>>>>
>>>> But may be not, may be gsscontext.getDelegCr() has to be called.
>>>>
>>>> I think that a case like this has to be managed in a simpler way in
>>>> CXF, though probably at the moment the way you suggest is the way to go.
>>>>
>>>> I've just added a jaxrs filter but I can definitely push most of the
>>>> code to the CXF in interceptor. This filter currently validates the
>>>> in service ticket only plus sets a basic SecurityContext. However it
>>>> can be configured to propagate the other useful info for
>>>> SpnegoAuthSupplier to reuse when this info is available on the
>>>> message...
>>>>
>>>> Hope you can make it all work - please share the code when you are
>>>> done and we can put some of it at the base CXF level
>>>>
>>>> Cheers, Sergey
>>>
>>
>>
>
>
> 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, d
 i
stributing 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.
> ________________________________


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
By the way, SpnegoAuthSupplier now checks for GSSCredential on the CXF
message and will use it if it is there to get a new token - that might
simplify a bit the propagation in the future for cases when no CXF is
involved to get the original in request

Sergey
On 18/07/12 17:10, Sergey Beryozkin wrote:

> Hi Josef
> On 18/07/12 15:47, Josef Bajada wrote:
>> Hi Sergey,
>>
>> In my case the endpoint is a simple<jaxws:client> specified in the
>> Spring app-context and injected to a few Controllers or similar classes.
>>
>> The only extra thing is that we want to 'impersonate' or 'delegate'
>> the user's credentials so that any call we do from the Web Service
>> client appears as if it is being done by the logged in user (the
>> Tomcat principal of the web app which is in fact the client of the web
>> service).
>>
> Thanks, that answers my question. Specifically, no CXF is involved to
> accept the request, it's only used to make the outbound request.
>
> As I've mentioned in the previous message, a server-side CXF filter is
> now available which manages the Negotiate scheme and can be used to make
> it pretty easy to propagate the available user credential, provided it
> is available, over to the outbound client.
> However this filter would be of interest only if CXF also acted as a
> receiver of the original request
>
> Cheers, Sergey
>
>> Josef
>>
>>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:[hidden email]]
>> Sent: 18 July 2012 14:33
>> To: [hidden email]
>> Subject: Re: Kerberos authentication using delegation from Principal
>> Ticket
>>
>> On 18/07/12 13:05, Sergey Beryozkin wrote:
>>> Hi Christian, All
>>> On 18/07/12 10:06, Christian Schneider wrote:
>>>> Hi Sergey and Josef,
>>>>
>>>> in Kerberos there are two kinds of tickets. The Ticket Granting
>>>> Ticket
>>>> (TGT) together with a session key is the one issued for the user
>>>> after he authenticates on his machine. This ticket then allows to get
>>>> a Service Ticket (ST) for a certain server. This service ticket is
>>>> typically then forwarded to the webserver during SPNEGO.
>>>>
>>>> So on the server side we can use the ST to authenticate the user but
>>>> I am not sure how we can use it to get a Service Token for the next
>>>> server. In standard Kerberos this is not possible as far as I know
>>>> but Microsoft has a Kerberos extension that allows this. I am not
>>>> sure though if this can be used from Java.
>>>>
>>>> In any case the username alone is obviously not enough to get another
>>>> ticket. What may be possible is to establish an authentication
>>>> context using subject.doAs after the authentication using the ST. In
>>>> this context it may then be possible to get another ST but I am not
>>>> sure how this works.
>>>>
>>>> So using an STS or Fediz may be the more solid way to solve this.
>>>>
>>>
>>> The quick test shows that the the server side validator is capable of
>>> getting GSSCredential using GSSContext.getDelegCred() (the method name
>>> is a bit cryptic I have to say :-)) but only if the initiator
>>> (SpnegoAuthSupplier) sets the cred delegation property to true (or I
>>> assume if the relevant login process say at the Tomcat level allows
>>> for it).
>>>
>>> Next, SpnegoAuthSupplier needs to check if GSSCredential is already
>>> available on the message and if yes, just pass it to the context
>>> creation call and let the context populate the token, without
>>> attempting to log in again.
>>>
>>> The delegated GSSCredential can be set by the code, before a WS/RS
>>> client is invoked again.
>>>
>>> I'm going to do few minor updates (at the JAX-RS level first) and then
>>> push them to CXF interceptors, for cases like the one Josef is dealing
>>> with easily handled at WS call level too
>>
>> I've done the updates but I'm going to wait with pushing the server
>> side negotiate handler code to CXF interceptor. Colm has implemented
>> the advanced WS-Security level Kerberos support, but I'm not sure it
>> can be needed at the CXF WS end without WS-Sec
>>
>> Josef, in your case, how the endpoint is implemented ? Is CXF involved
>> at all, except for the need to do the outbound call with CXF ?
>>
>> Sergey
>>>> Christian
>>>>
>>>> Am 18.07.2012 01:15, schrieb Sergey Beryozkin:
>>>>> Hi Josef
>>>>>
>>>>> On 18/07/12 00:03, Josef Bajada wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Yes the Principal will be available (i.e. the Username).
>>>>>>
>>>>>> I am thinking that we will need to generate the new token for the
>>>>>> remote service (Sharepoint) from the original Token we had received
>>>>>> from the browser. So we would need to do gsscontext.getDelegCr() to
>>>>>> get the Delegate Credentials for the user and get the new token
>>>>>> from that, so that we put it in the outbound HTTP header.
>>>>>>
>>>>>> As far as I know (again I could be mistaken), the old ticket would
>>>>>> be only valid for our URL (SPN), and a new one would be needed for
>>>>>> the Sharepoint URL.
>>>>>
>>>>> That is pretty interesting. I just happen to have spent few days
>>>>> only on the subject, so hope our security experts can help :-).
>>>>>
>>>>> I thought that the tickets that can be 'forwarded' if the kdc
>>>>> configuration allows for that.
>>>>>
>>>>> But may be not, may be gsscontext.getDelegCr() has to be called.
>>>>>
>>>>> I think that a case like this has to be managed in a simpler way in
>>>>> CXF, though probably at the moment the way you suggest is the way
>>>>> to go.
>>>>>
>>>>> I've just added a jaxrs filter but I can definitely push most of the
>>>>> code to the CXF in interceptor. This filter currently validates the
>>>>> in service ticket only plus sets a basic SecurityContext. However it
>>>>> can be configured to propagate the other useful info for
>>>>> SpnegoAuthSupplier to reuse when this info is available on the
>>>>> message...
>>>>>
>>>>> Hope you can make it all work - please share the code when you are
>>>>> done and we can put some of it at the base CXF level
>>>>>
>>>>> Cheers, Sergey
>>>>
>>>
>>>
>>
>>
>> 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, di
> stributing 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.
>> ________________________________
>
>

jbx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Kerberos authentication using delegation from Principal Ticket

jbx
Hi Sergey,

Thanks for that!

So, if we manage to get access to the GSSCredential object, how would we add it to the request being made so that the SpnegoAuthSupplier finds it?
What method calls do we need to do to the CXF Jax-ws client injected by spring so that we add the GSSCredential object?

Cheers,

Josef


-----Original Message-----
From: Sergey Beryozkin [mailto:[hidden email]]
Sent: 18 July 2012 18:17
To: [hidden email]
Subject: Re: Kerberos authentication using delegation from Principal Ticket

By the way, SpnegoAuthSupplier now checks for GSSCredential on the CXF message and will use it if it is there to get a new token - that might simplify a bit the propagation in the future for cases when no CXF is involved to get the original in request

Sergey
On 18/07/12 17:10, Sergey Beryozkin wrote:

> Hi Josef
> On 18/07/12 15:47, Josef Bajada wrote:
>> Hi Sergey,
>>
>> In my case the endpoint is a simple<jaxws:client> specified in the
>> Spring app-context and injected to a few Controllers or similar classes.
>>
>> The only extra thing is that we want to 'impersonate' or 'delegate'
>> the user's credentials so that any call we do from the Web Service
>> client appears as if it is being done by the logged in user (the
>> Tomcat principal of the web app which is in fact the client of the
>> web service).
>>
> Thanks, that answers my question. Specifically, no CXF is involved to
> accept the request, it's only used to make the outbound request.
>
> As I've mentioned in the previous message, a server-side CXF filter is
> now available which manages the Negotiate scheme and can be used to
> make it pretty easy to propagate the available user credential,
> provided it is available, over to the outbound client.
> However this filter would be of interest only if CXF also acted as a
> receiver of the original request
>
> Cheers, Sergey
>
>> Josef
>>
>>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:[hidden email]]
>> Sent: 18 July 2012 14:33
>> To: [hidden email]
>> Subject: Re: Kerberos authentication using delegation from Principal
>> Ticket
>>
>> On 18/07/12 13:05, Sergey Beryozkin wrote:
>>> Hi Christian, All
>>> On 18/07/12 10:06, Christian Schneider wrote:
>>>> Hi Sergey and Josef,
>>>>
>>>> in Kerberos there are two kinds of tickets. The Ticket Granting
>>>> Ticket
>>>> (TGT) together with a session key is the one issued for the user
>>>> after he authenticates on his machine. This ticket then allows to
>>>> get a Service Ticket (ST) for a certain server. This service ticket
>>>> is typically then forwarded to the webserver during SPNEGO.
>>>>
>>>> So on the server side we can use the ST to authenticate the user
>>>> but I am not sure how we can use it to get a Service Token for the
>>>> next server. In standard Kerberos this is not possible as far as I
>>>> know but Microsoft has a Kerberos extension that allows this. I am
>>>> not sure though if this can be used from Java.
>>>>
>>>> In any case the username alone is obviously not enough to get
>>>> another ticket. What may be possible is to establish an
>>>> authentication context using subject.doAs after the authentication
>>>> using the ST. In this context it may then be possible to get
>>>> another ST but I am not sure how this works.
>>>>
>>>> So using an STS or Fediz may be the more solid way to solve this.
>>>>
>>>
>>> The quick test shows that the the server side validator is capable
>>> of getting GSSCredential using GSSContext.getDelegCred() (the method
>>> name is a bit cryptic I have to say :-)) but only if the initiator
>>> (SpnegoAuthSupplier) sets the cred delegation property to true (or I
>>> assume if the relevant login process say at the Tomcat level allows
>>> for it).
>>>
>>> Next, SpnegoAuthSupplier needs to check if GSSCredential is already
>>> available on the message and if yes, just pass it to the context
>>> creation call and let the context populate the token, without
>>> attempting to log in again.
>>>
>>> The delegated GSSCredential can be set by the code, before a WS/RS
>>> client is invoked again.
>>>
>>> I'm going to do few minor updates (at the JAX-RS level first) and
>>> then push them to CXF interceptors, for cases like the one Josef is
>>> dealing with easily handled at WS call level too
>>
>> I've done the updates but I'm going to wait with pushing the server
>> side negotiate handler code to CXF interceptor. Colm has implemented
>> the advanced WS-Security level Kerberos support, but I'm not sure it
>> can be needed at the CXF WS end without WS-Sec
>>
>> Josef, in your case, how the endpoint is implemented ? Is CXF
>> involved at all, except for the need to do the outbound call with CXF ?
>>
>> Sergey
>>>> Christian
>>>>
>>>> Am 18.07.2012 01:15, schrieb Sergey Beryozkin:
>>>>> Hi Josef
>>>>>
>>>>> On 18/07/12 00:03, Josef Bajada wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Yes the Principal will be available (i.e. the Username).
>>>>>>
>>>>>> I am thinking that we will need to generate the new token for the
>>>>>> remote service (Sharepoint) from the original Token we had
>>>>>> received from the browser. So we would need to do
>>>>>> gsscontext.getDelegCr() to get the Delegate Credentials for the
>>>>>> user and get the new token from that, so that we put it in the outbound HTTP header.
>>>>>>
>>>>>> As far as I know (again I could be mistaken), the old ticket
>>>>>> would be only valid for our URL (SPN), and a new one would be
>>>>>> needed for the Sharepoint URL.
>>>>>
>>>>> That is pretty interesting. I just happen to have spent few days
>>>>> only on the subject, so hope our security experts can help :-).
>>>>>
>>>>> I thought that the tickets that can be 'forwarded' if the kdc
>>>>> configuration allows for that.
>>>>>
>>>>> But may be not, may be gsscontext.getDelegCr() has to be called.
>>>>>
>>>>> I think that a case like this has to be managed in a simpler way
>>>>> in CXF, though probably at the moment the way you suggest is the
>>>>> way to go.
>>>>>
>>>>> I've just added a jaxrs filter but I can definitely push most of
>>>>> the code to the CXF in interceptor. This filter currently
>>>>> validates the in service ticket only plus sets a basic
>>>>> SecurityContext. However it can be configured to propagate the
>>>>> other useful info for SpnegoAuthSupplier to reuse when this info
>>>>> is available on the message...
>>>>>
>>>>> Hope you can make it all work - please share the code when you are
>>>>> done and we can put some of it at the base CXF level
>>>>>
>>>>> Cheers, Sergey
>>>>
>>>
>>>
>>
>>
>> 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, di
> stributing 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

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.
________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
Hi,
On 18/07/12 19:44, Josef Bajada wrote:
> Hi Sergey,
>
> Thanks for that!
>
> So, if we manage to get access to the GSSCredential object, how would we add it to the request being made so that the SpnegoAuthSupplier finds it?
> What method calls do we need to do to the CXF Jax-ws client injected by spring so that we add the GSSCredential object?
>

In this case adding the following will do:

<jaxws:properties>
   <propery name="org.ietf.jgss.GSSCredential" ref="gssCredential">
</jaxws:properties>

However I typed message.get("org.ietf.jgss.GSSCredential") in the code
to check for the available GSSCredential, may need to change it to
message.getContextualProperty. I've also broken the build with my latest
lame commit, otherwise you'd be able to try CXF 2.6.2-SNAPSHOTS tomorrow
or so

Cheers, Sergey

> Cheers,
>
> Josef
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:[hidden email]]
> Sent: 18 July 2012 18:17
> To: [hidden email]
> Subject: Re: Kerberos authentication using delegation from Principal Ticket
>
> By the way, SpnegoAuthSupplier now checks for GSSCredential on the CXF message and will use it if it is there to get a new token - that might simplify a bit the propagation in the future for cases when no CXF is involved to get the original in request
>
> Sergey
> On 18/07/12 17:10, Sergey Beryozkin wrote:
>> Hi Josef
>> On 18/07/12 15:47, Josef Bajada wrote:
>>> Hi Sergey,
>>>
>>> In my case the endpoint is a simple<jaxws:client>  specified in the
>>> Spring app-context and injected to a few Controllers or similar classes.
>>>
>>> The only extra thing is that we want to 'impersonate' or 'delegate'
>>> the user's credentials so that any call we do from the Web Service
>>> client appears as if it is being done by the logged in user (the
>>> Tomcat principal of the web app which is in fact the client of the
>>> web service).
>>>
>> Thanks, that answers my question. Specifically, no CXF is involved to
>> accept the request, it's only used to make the outbound request.
>>
>> As I've mentioned in the previous message, a server-side CXF filter is
>> now available which manages the Negotiate scheme and can be used to
>> make it pretty easy to propagate the available user credential,
>> provided it is available, over to the outbound client.
>> However this filter would be of interest only if CXF also acted as a
>> receiver of the original request
>>
>> Cheers, Sergey
>>
>>> Josef
>>>
>>>
>>> -----Original Message-----
>>> From: Sergey Beryozkin [mailto:[hidden email]]
>>> Sent: 18 July 2012 14:33
>>> To: [hidden email]
>>> Subject: Re: Kerberos authentication using delegation from Principal
>>> Ticket
>>>
>>> On 18/07/12 13:05, Sergey Beryozkin wrote:
>>>> Hi Christian, All
>>>> On 18/07/12 10:06, Christian Schneider wrote:
>>>>> Hi Sergey and Josef,
>>>>>
>>>>> in Kerberos there are two kinds of tickets. The Ticket Granting
>>>>> Ticket
>>>>> (TGT) together with a session key is the one issued for the user
>>>>> after he authenticates on his machine. This ticket then allows to
>>>>> get a Service Ticket (ST) for a certain server. This service ticket
>>>>> is typically then forwarded to the webserver during SPNEGO.
>>>>>
>>>>> So on the server side we can use the ST to authenticate the user
>>>>> but I am not sure how we can use it to get a Service Token for the
>>>>> next server. In standard Kerberos this is not possible as far as I
>>>>> know but Microsoft has a Kerberos extension that allows this. I am
>>>>> not sure though if this can be used from Java.
>>>>>
>>>>> In any case the username alone is obviously not enough to get
>>>>> another ticket. What may be possible is to establish an
>>>>> authentication context using subject.doAs after the authentication
>>>>> using the ST. In this context it may then be possible to get
>>>>> another ST but I am not sure how this works.
>>>>>
>>>>> So using an STS or Fediz may be the more solid way to solve this.
>>>>>
>>>>
>>>> The quick test shows that the the server side validator is capable
>>>> of getting GSSCredential using GSSContext.getDelegCred() (the method
>>>> name is a bit cryptic I have to say :-)) but only if the initiator
>>>> (SpnegoAuthSupplier) sets the cred delegation property to true (or I
>>>> assume if the relevant login process say at the Tomcat level allows
>>>> for it).
>>>>
>>>> Next, SpnegoAuthSupplier needs to check if GSSCredential is already
>>>> available on the message and if yes, just pass it to the context
>>>> creation call and let the context populate the token, without
>>>> attempting to log in again.
>>>>
>>>> The delegated GSSCredential can be set by the code, before a WS/RS
>>>> client is invoked again.
>>>>
>>>> I'm going to do few minor updates (at the JAX-RS level first) and
>>>> then push them to CXF interceptors, for cases like the one Josef is
>>>> dealing with easily handled at WS call level too
>>>
>>> I've done the updates but I'm going to wait with pushing the server
>>> side negotiate handler code to CXF interceptor. Colm has implemented
>>> the advanced WS-Security level Kerberos support, but I'm not sure it
>>> can be needed at the CXF WS end without WS-Sec
>>>
>>> Josef, in your case, how the endpoint is implemented ? Is CXF
>>> involved at all, except for the need to do the outbound call with CXF ?
>>>
>>> Sergey
>>>>> Christian
>>>>>
>>>>> Am 18.07.2012 01:15, schrieb Sergey Beryozkin:
>>>>>> Hi Josef
>>>>>>
>>>>>> On 18/07/12 00:03, Josef Bajada wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> Yes the Principal will be available (i.e. the Username).
>>>>>>>
>>>>>>> I am thinking that we will need to generate the new token for the
>>>>>>> remote service (Sharepoint) from the original Token we had
>>>>>>> received from the browser. So we would need to do
>>>>>>> gsscontext.getDelegCr() to get the Delegate Credentials for the
>>>>>>> user and get the new token from that, so that we put it in the outbound HTTP header.
>>>>>>>
>>>>>>> As far as I know (again I could be mistaken), the old ticket
>>>>>>> would be only valid for our URL (SPN), and a new one would be
>>>>>>> needed for the Sharepoint URL.
>>>>>>
>>>>>> That is pretty interesting. I just happen to have spent few days
>>>>>> only on the subject, so hope our security experts can help :-).
>>>>>>
>>>>>> I thought that the tickets that can be 'forwarded' if the kdc
>>>>>> configuration allows for that.
>>>>>>
>>>>>> But may be not, may be gsscontext.getDelegCr() has to be called.
>>>>>>
>>>>>> I think that a case like this has to be managed in a simpler way
>>>>>> in CXF, though probably at the moment the way you suggest is the
>>>>>> way to go.
>>>>>>
>>>>>> I've just added a jaxrs filter but I can definitely push most of
>>>>>> the code to the CXF in interceptor. This filter currently
>>>>>> validates the in service ticket only plus sets a basic
>>>>>> SecurityContext. However it can be configured to propagate the
>>>>>> other useful info for SpnegoAuthSupplier to reuse when this info
>>>>>> is available on the message...
>>>>>>
>>>>>> Hope you can make it all work - please share the code when you are
>>>>>> done and we can put some of it at the base CXF level
>>>>>>
>>>>>> Cheers, Sergey
>>>>>
>>>>
>>>>
>>>
>>>
>>> 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, di
>> stributing 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
>
> 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, d
 i
stributing 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.
> ________________________________
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

cschneider
I don´t think a static gssCredential in the spring config can help. The
credentials may be different on each call.

Instead I think we need to set the property on the client just before
the call. This is how it would look in the wsdl_first example:

         org.apache.cxf.endpoint.Client client =
          org.apache.cxf.frontend.ClientProxy.getClient(customerService);
         client.setThreadLocalRequestContext(true);
         Map<String, Object> reqContext = client.getRequestContext();
         reqContext.put("org.ietf.jgss.GSSCredential", gssCredentials);
         customers = customerService.getCustomersByName("Smith");

Not sure if this works but it should be worth a try.

Christian


Am 18.07.2012 23:47, schrieb Sergey Beryozkin:

> Hi,
> On 18/07/12 19:44, Josef Bajada wrote:
>> Hi Sergey,
>>
>> Thanks for that!
>>
>> So, if we manage to get access to the GSSCredential object, how would
>> we add it to the request being made so that the SpnegoAuthSupplier
>> finds it?
>> What method calls do we need to do to the CXF Jax-ws client injected
>> by spring so that we add the GSSCredential object?
>>
>
> In this case adding the following will do:
>
> <jaxws:properties>
>   <propery name="org.ietf.jgss.GSSCredential" ref="gssCredential">
> </jaxws:properties>
>
> However I typed message.get("org.ietf.jgss.GSSCredential") in the code
> to check for the available GSSCredential, may need to change it to
> message.getContextualProperty. I've also broken the build with my
> latest lame commit, otherwise you'd be able to try CXF 2.6.2-SNAPSHOTS
> tomorrow or so
>
> Cheers, Sergey

--
 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kerberos authentication using delegation from Principal Ticket

Sergey Beryozkin
Hi Christian
On 19/07/12 06:53, Christian Schneider wrote:
> I don´t think a static gssCredential in the spring config can help. The
> credentials may be different on each call.
>
I thought Spring would be able to offer some per-request wrapper :-)

> Instead I think we need to set the property on the client just before
> the call. This is how it would look in the wsdl_first example:
>
> org.apache.cxf.endpoint.Client client =
> org.apache.cxf.frontend.ClientProxy.getClient(customerService);
> client.setThreadLocalRequestContext(true);
> Map<String, Object> reqContext = client.getRequestContext();
> reqContext.put("org.ietf.jgss.GSSCredential", gssCredentials);
> customers = customerService.getCustomersByName("Smith");
>
> Not sure if this works but it should be worth a try.
>
Yeah, that is possible too - another option is to get a GSSCredential
retrieved from within a custom out interceptor (itself registered from
Spring) and then set it on a current message. I guess much depends on
the way the credential can be actually obtained from the original
SecurityContext which Tomcat and/or Spring Sec create, lets see what
solution Josef will find :-).

Cheers, Sergey

> Christian
>
>
> Am 18.07.2012 23:47, schrieb Sergey Beryozkin:
>> Hi,
>> On 18/07/12 19:44, Josef Bajada wrote:
>>> Hi Sergey,
>>>
>>> Thanks for that!
>>>
>>> So, if we manage to get access to the GSSCredential object, how would
>>> we add it to the request being made so that the SpnegoAuthSupplier
>>> finds it?
>>> What method calls do we need to do to the CXF Jax-ws client injected
>>> by spring so that we add the GSSCredential object?
>>>
>>
>> In this case adding the following will do:
>>
>> <jaxws:properties>
>> <propery name="org.ietf.jgss.GSSCredential" ref="gssCredential">
>> </jaxws:properties>
>>
>> However I typed message.get("org.ietf.jgss.GSSCredential") in the code
>> to check for the available GSSCredential, may need to change it to
>> message.getContextualProperty. I've also broken the build with my
>> latest lame commit, otherwise you'd be able to try CXF 2.6.2-SNAPSHOTS
>> tomorrow or so
>>
>> Cheers, Sergey
>


12
Loading...