[security-dev] any way to store global information?

[Stefan Guilhen]

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/LoginModule.html
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev