Security Domain Config: JASPI vs Classic?

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 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.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Bill Burke
In reply to this post by Anil Saldhana


On 10/7/11 12: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.
>

Again, this can be a *BAD* thing.  Cache decisions can and should be a
property of the underlying store.  An example is an HTTP-based IDP which
uses Cache-Control semantics to specify cache policies for an identity.

This is all besides the fact...The current model of JAAS modules isn't
very flexible and has lead to a lot of bad design decisions.  IMO at least.

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

What are you talking about?  This is an implementation detail of the
storage mechanism and really has nothing to do with the problems of the
current API/SPI or any new SPI that is introduced.

Bill

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Security Domain Config: JASPI vs Classic?

Bill Burke
In reply to this post by Anil Saldhana


On 10/7/11 9:21 AM, Anil Saldhana wrote:
> 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?
>

Doesn't matter if the CBH itself caches state or not.  It could delegate
to a service reference, or not.  IMO though, they need the option to be
stateful.

What the CBH's do, is give a *typed* interface that is *storage-type
agnostic* to query for authentication information.  THis way auth
algorithms can be decoupled from the storage mechanism.  Much of this is
already built into the JSAPI from what I understand.


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

This is just *one* problem of the current API.  Its broken.  Needs to be
fixed.  I don't know how many times I have to say it.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12