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

[Anil Saldhana]

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.