[jboss-as7-dev] Security Domain Config: JASPI vs Classic?

[Darran Lofthouse]

No CallbackHandlers don't need to be stateful, they do tend to require 
some form of access to a backing store but there is no need for the 
actual state to be held within the CallbackHandler - the CallbackHandler 
is just a proxy to this store.

Saying that picking up changes to a properties file would require a 
server reboot is like saying picking up a users changed password or 
roles from the DB after they have connected also requires a reboot. 
There are various options to pick up a modified properties file without 
restarting the server.

Regards,
Darran Lofthouse.


On 10/07/2011 05:18 AM, Anil Saldhana wrote:
> Jaas framework was created before EE adopted it. It is supposed to be a
> stateless model.
>
> CBH are stateful.  The authentication cache in the JBoss security
> subsystem caches entries at the security domain level. There is no need
> to go to the jaas framework every time you need to authenticate an user.
> If the cache is missed, that is when you invoke the stateless jaas
> framework with a stateful cbh.  After successful auth, cache is updated.
>
> Why would I cache a properties data?  Each time I want to add an user to
> the props file, I have to bounce the server? Also in regular usage of
> JBoss apps, we do not recommend the users/roles props security.
>
> On 10/04/2011 10:42 AM, Bill Burke wrote:
>> On 10/4/11 11:13 AM, Darran Lofthouse wrote:
>>> On 10/04/2011 03:29 PM, Bill Burke wrote:
>>>> Callback handlers would give you a "storage" abstraction driven by any
>>>> arbitrary interface.  We'd implement a different SPI for it
>>> One thing this does change is that the location of any caching based on
>>> the authentication needs to be moved to a different location and in a
>>> different context.
>>>
>> Ya, the whole caching mechanism of JBoss security APIs are built on the
>> premise that LoginModules are stateless.  This goes to the point I've
>> made in the past that if you're building your code on top of a flawed
>> architecture you're going to have flawed code no matter how good of an
>> engineer you are.  Its time to redefine the problem.
>>
>> In the API/SPI i'm proposing CallbackHandlers are stateful and thus can
>> decide whether or not to cache information.
>>
>> For example, it doesn't make sense to reload the user.properties file,
>> for every single new user (which I believe our code actually does).
>> Just load it up once and cache it within memory. For LDAP integration,
>> it does make sense to cache individual user/password combos.  An HTTP
>> based IDP could use Cache-Control protocol to tell the IDP's callback
>> handler how to cache.
>>
>> So the caching mechansim really depends on the "security storage
>> mechanism".  The CallbackHandler interface and config I'm proposing
>> totally abstracts this out.
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev