Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.215.169 as permitted sender)
Message-ID: <5006A6A0.9050003@gmail.com>
Date: Wed, 18 Jul 2012 13:05:52 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: Kerberos authentication using delegation from Principal Ticket
References: <029F19A0A3828F409E2F145593359C0E0BE40E@MSEMBox1.corporate.intra>
 <5005E849.4090005@gmail.com>
 <029F19A0A3828F409E2F145593359C0E0BE4BB@MSEMBox1.corporate.intra>
 <5005EBDD.8050600@gmail.com>
 <029F19A0A3828F409E2F145593359C0E0BE4D8@MSEMBox1.corporate.intra>
 <5005F20B.9090309@gmail.com> <50067C8D.3080800@die-schneider.net>
In-Reply-To: <50067C8D.3080800@die-schneider.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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