Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Better default identity handling

Actually.....

the second problem is not a problem as we already set the IdentityService
of a DeferredAuthentication to null, so it can't authenticate after it
leaves the SecurityHandler.

The first problem is easy to solve with an extra field in the
DeferredAuthentication to hold the previous value and the SecurityHandler
queries that.

So I think if this passes some tests, I'm good to commit.

cheers




Greg Wilkins wrote:
> David,
> 
> I have no problem with this in general... but there is a practical problem.
> 
> Because of the DefferedAuthentication type and the ability of application
> code to call the new authenticate methods, this now means that an associate
> might happen not from the SecurityHandler call.    This causes two problem:
> 
> 1) How does the security handler get hold of the returned Object so that
> disassociate can be called?
> 
> 2) What happens if an async handler calls authenticate outside of the
> scope of the security Handler (hmmm I think this is a problem anyway).
> 
> 
> So I'm not sure if you can have a null auth meaning no established
> identity.  I think you always need to have a DeferredAuthentication.
> 
> Ping me in your morning and we can discuss on IRC.
> 
> cheers
> 
> 
> 
> David Jencks wrote:
>> In geronimo we're having a problem installing default identity on
>> threads that don't actually authenticate.  After studying the situation
>> for a while I think the following solution is about the best possible. 
>> It lets the IdentityService be notified whenever a request is going to
>> be handled: if the identity passed in is null it is free to do whatever
>> it wants such as establish a default identity.   Since "null" now means
>> "no established identity" we also need a disassociate method, and this
>> give the opportunity to restore whatever context info might have been
>> previously present.  Thoughts or objections?  The Geronimo issue
>> tracking our problems is 
>> https://issues.apache.org/jira/browse/GERONIMO-4756
>>


Back to the top