3:48 p.m.
IMO the JAAS classes offer very restricted interfaces. The inability to
store state between multiple JAAS logins is an example of that, showing
how much of a pain it is when you need to customize the login process.
You could probably use the CallbackHandler to store all the data, but
that is not really a good idea since the handler requires callbacks to
retrieve info and this will either force you to implement callbacks for
each piece of data you have stored or make the login modules cast the
handler to the specific type you implemented and then use getter methods
to retrieve data.
To me, the best approach for this would be to have the ability to
specify the sharedState map before the login process is triggered.
Ideally this should be in the LoginContext interface so you can just set
the state once and trust the context to populate the shared state map
that is passed to the modules. Something along the lines of new
LoginContext(configName, subject, handler, sharedStateMap) and maybe
methods in the API to add\remove stuff from the map, etc.
Since this is not currently possible using the JDK JAAS API, I believe
we should consider implementing our own LoginContext class in PicketBox
(fork and improve, whatever) to cover scenarios like this.
Just my 2c.
Stefan
On 09/12/2012 04:45 PM, Anil Saldhana wrote:
On 09/12/2012 02:42 PM, Bill Burke wrote:
> On 9/12/2012 2:21 PM, Anil Saldhana wrote:
>> The JDK Jaas stack is an expensive operation that is performed each time
>> you go to the LoginContext.login() process. The login modules are
>> created via class.forname and then set a shared map etc.
>>
>> So for each stack invocation, you can use the shared state/map/options
>> for caching information and pass around the modules. But you cannot use
>> it across lets say 10 JAAS login attempts. For that, you will have to
>> look at some caching mechanism at the security subsystem or container level.
>>
> #1 My login module requires shutting off the cache as it is obtaining
> role mappigs from the HTTP request.
>
> #2. I Don't understand what you're saying about the options map. It
> gets destroyed and reinitialized after 10 login attempts? WTF? What I
> want to store in the options map is pre-initialized connections to a
> remote endpoint so I don't have to do this setup on every login request.
>
http://docs.oracle.com/javase/6/docs/api/javax/security/auth/spi/LoginMod...
The shared state and options in login modules get created and destroyed
after every JAAS invocation. I just meant if you want to share stuff
across jaas logins, then you have to look at an external cache (nothing
related to jaas stuff). Forget the 10.
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev