Re: [jboss-as7-dev] Security Domain Config: JASPI vs Classic?
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev