Would adding support for client credential delegation be out of scope
for this implementation or not?
Client credential delegation is when you use the spnego token
construct a javax.security.auth.Subject instance that represents the
client - which the server side application can use this to impersonate
the client (eg. connect to some Kerberized database as the client that
sent the request, or consume some other kerberized service as the
client).
The code for creating such a Subject would be something like this:
GSSContext context =
GSSManager.getInstance().createContext((GSSCredential) null);
context.acceptSecContext(...);
//check if the credentials can be delegated
if (!context.getCredDelegState()) {
//get the delegated credentials from the calling peer...
GSSCredential clientCred = context.getDelegCred();
//Create a Subject out of the delegated credentials.
//With this Subject the application server can impersonate the
client that sent the request.
Subject clientSubject =
com.sun.security.jgss.GSSUtil.createSubject(context.getSrcName(),
clientCred);
}
//Store the clientSubject somewhere - maybe to the HttpServletRequest?
I am sure this would be useful for some applications - for example the
one that we are currently developing needs functionality like this.
On Tue, Mar 29, 2011 at 9:09 PM, Mark Thomas <ma...@apache.org> wrote:
> On 29/03/2011 15:20, Mark Thomas wrote:
>> On 28/03/2011 22:31, Stefan Mayr wrote:
>>> Native SPNEGO in Tomcat sounds great. Waiting a little while depends on
>>> your scale of "little". Is there already some development we can follow?
>>> Will this use Java GSS? I never figured out how to configure this with
>>> Tomcat.
>>
>> "little" hopefully means the next week or so in a 7.0.12 release. I have
>> a handful of things I need/want to get into 7.0.12 and SPNEGO is one of
>> them.
>>
>> Having spent more time than I want to think about and having lost count
>> of the number of times I re-installed Windows 2k8 server to test this, I
>> finally got this working a few minutes ago. The current code is *very*
>> rough and ready and it only does authentication, not authorisation so I
>> still have some work to do.
>>
>> The solution is based on ideas from Spring Security's Kerberos extension
>> and the most recent patches attached to bug 48685.
>>
>> I'll be committing an initial implementation once I have cleaned up the
>> code a bit and then I'll build on that to add authorisation, more
>> configuration etc.
>
> The first part just got committed [1]. More to follow over the next day
> or so.
>
> Mark
>
> [1] http://svn.apache.org/viewvc?rev=1086683&view=rev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
Why?
Because YES!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
