cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josef Bajada <Josef.Baj...@go.com.mt>
Subject RE: Kerberos authentication using delegation from Principal Ticket
Date Wed, 18 Jul 2012 18:44:48 GMT
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:sberyozkin@gmail.com]
Sent: 18 July 2012 18:17
To: users@cxf.apache.org
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:sberyozkin@gmail.com]
>> Sent: 18 July 2012 14:33
>> To: users@cxf.apache.org
>> 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.
________________________________

Mime
View raw message