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
