Re: [Springframework-developer] Re: [Acegisecurity-developer] Acegi Security's ContextHolder replaced by SecurityContext

[Colin S. <col...@ex...>]

Colin Sampaleanu wrote:

> Ben Alex wrote:
>
>> Pursuant to Juergen's recommendation 
>> (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), 
>> Acegi Security CVS has now had its ContextHolder and related classes 
>> removed. This functionality has been replaced by SecurityContext, 
>> which is an InheritableThreadLocal that provides a single 
>> getter/setter pair for Authentication.
>>
>> This is a significant change for end users, but offers a number of 
>> benefits:
>>
>> - Consistency with Spring core's use of a concrete ThreadLocal per 
>> functional area
>> - SecurityContext is strictly typed (which eliminates the need for 
>> casting)
>> - Simplified configuration as no need to specify a Context 
>> implementation for HttpSessionContextIntegrationFilter
>> - InheritableThreadLocal used instead of ThreadLocal to simplify rich 
>> client usage (see http://forum.springframework.org/viewtopic.php?t=5004)
>> - Elimination of handling the extra Context layer means less end user 
>> code is required
>>
>> Unit tests pass and I've updated the upgrade-080-090.txt in some 
>> detail. The reference guide has also been updated.
>>
>> It would be appreciated if developers could try the latest CVS with 
>> their applications and report any difficulties. General feedback on 
>> this change is also welcome.
>
>
> As I read Juergen's suggestion, I thought he was just suggesting to go 
> away from the ContextHolder with abitlity to hold a generic Context, 
> as it is potentially confusing as to what is going to go in there. So 
> he suggested a SecurityContextHolder which needs to hold a 
> SecurityContext.
>
> However, it seems to me that this simplification is much more than 
> that, and may have gone too far, as it's all been collapsed into the 
> one SecurityContext which is the threadlocal (effectively) and holds 
> the Authentication. Unless I'm missing something it would still be of 
> real use to have a real SecurityContextHolder which holds a pluggable 
> SecurityContext. Then people can subclass that if needed to add extra 
> data. The difference from before however is that now it is clearly 
> security focused, and the lifecycle of the object is managed clearly 
> by Acegi.
>
> What does everybody think?
>
As a follow-up, from memory (it's been about a year) I believe I used a 
custom SecureContext to also pass along some EJB related security 
information (principal name, or the ejb run-as user) between different 
layers along with the Acegi specific info. The app in question was a 
mixed EJB and Spring app, using the EJB version of OSWorkflow.

In general, I think if by default the user does not have to specify the 
actual SecurityContext implementation class unless they want to override 
it, and the SecurityContextHolder ensures there is always a 
SecureContext (throwing an exception if it's set to null), then even 
with the separate SecurityContextContextHolder and 
SecurityContextContext, it's still way less verbose than the old 
classes, and just about as convenient to use as with the completely 
collapsed version, i.e.
    SecurityContextHolder.getSecurityContext().getAuthentication();

This essentially allows users to associate any information that 
logically belongs with the current security context with the context, 
and it is clear that the lifecycle of the security context is managed by 
Acegi Security, unlike the old classes. Ben has pointed out that you can 
always use a custom UserDetails implementation. This is true, but 
implicates AuthenticationDao and the UserDetails impl. where they 
shouldn't necessarilly be implicated.

Colin


-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com