6:04 p.m.
Any way to store global information so that different calls to
LoginModule.login() can share data, connections, etc.?
Thanks
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:15 p.m.
Can you put stuff in the options or shared state map that is passed to
LoginModule.initialize()?
On 9/12/2012 2:09 PM, Anil Saldhana wrote:
Not completely possible without use of some static cache.
On 09/12/2012 11:04 AM, Bill Burke wrote:
> Any way to store global information so that different calls to
> LoginModule.login() can share data, connections, etc.?
>
> Thanks
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:21 p.m.
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.
Historically, we have had an authentication manager cache that would
save username/credential (password or cert) and do cache authentication.
Only if there is failed cache login or a cache miss, would the jaas
stack get called. On success, the auth cache would be updated.
With the new PicketBox work, we can definitely consider some of your
requirements if you have any extra information.
On 09/12/2012 01:15 PM, Bill Burke wrote:
Can you put stuff in the options or shared state map that is passed
to
LoginModule.initialize()?
On 9/12/2012 2:09 PM, Anil Saldhana wrote:
> Not completely possible without use of some static cache.
>
> On 09/12/2012 11:04 AM, Bill Burke wrote:
>> Any way to store global information so that different calls to
>> LoginModule.login() can share data, connections, etc.?
>>
>> Thanks
>
9:42 p.m.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:45 p.m.
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.
10: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
4260
days inactive
4266
days old
6 comments
3 participants
participants (3)
-
Anil Saldhana -
Bill Burke -
Stefan Guilhen