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

[Anil Saldhana]

On 10/07/2011 04:32 AM, Darran Lofthouse wrote:
> 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.
Can Bill define what the constitution of state is so we know whether
cbh is stateful or not?

> 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.
For properties files, unless you reload them, there is no way you can
pick up changes. You can try to retain the last modified timestamp 
someplace,
to check whether you want to load them. Now that is added complexity IMO for
a mechanism that we should not recommend users use (unless for testing 
or simple usage).

>
> 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.