harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [classlib][auth]LoginContext should always invoke the LoginModules?
Date Mon, 09 Oct 2006 02:45:00 GMT
 > Understood, some occurrences are outside our control.  As you point out
 > above, we shall be good citizens to the best of our ability.

Yes. LoginModule-s are out of our control.
But we can control how the LoginContext invokes them, and we can be 
defensive this way.

I propose the following:

1. Leave the check that started this thread as-is:
	if (already_logged) {do_nothing}

2. As this introduces a difference with RI, then document the difference 
with the reason why:
the RI's behavior may introduce a resource leakage as result of 
invocation LoginModule.login() on already logged modules.

3. [?] For whose who has *really strong* need in the RI's behaviour, 
introduce a system property to turn it on.
Something like
-Dhy.jaas.auth.logincontext.use.unsafe.secondary.login = true/false, 
false by default.

	if (already_logged && !use_unsafe_secondary_login) {do_nothing}
	// fall-through to process over the login()-s.



Tim Ellison wrote:
> Alex Astapchuk wrote:
>> Tim Ellison wrote:
>>> Alex Astapchuk wrote:
>>>> Hi Stepan, all,
>>>>> I think the spec. statement: "A LoginContext should not be used to
>>>>> authenticate more than one Subject." was taken too strict: reusing
>>>>> LoginContext object to get the same set of credentials seemed odd.
>>>> The decision was mostly about resources.
>>>> Indeed, the spec does not specify behavior of LoginContext.
>>>> However, the spec is more or less clear in what should the
>>>> Login*Module*-s do in response to login/logout/etc.
>>>> It states 'login() saves result ...'. It does not warn with
>>>> anything like 'check previous state and clean up resources
>>>> from previous successful logins'.
>>>> The resource clean up is explicitly for abort() and logout().
>>> The spec might not say so explicitly, but cleaning up the resources
>>> before attempting another login would seem like a reasonable thing to do.
>> Oh yeah, with no doubt.
>> It's always good to be defensive, and careful, and accurate, and etc,
>> etc...
>> Especially when you're warned. :-)
>> The JAAS tutorial has a TODO-list for LoginModule.login() [1].
>> Nothing again about 'should check and clear'.
>>>>>> I consider RI's behavior is more reasonable.
>>>> I would say it's more dangerous.
>>>> The invocation of login() on already logged LoginModule-s
>>>> may easily produce a resource leak.
>>>> Presuming the authentication is normally not a too frequent
>>>> task, such a leak would be really hard to discover and hunt.
>>> I don't see why we would have to suffer the leak -- if the state changes
>>> are made via API then we have the opportunity to fix things first.
>> I was talking about custom LoginModule-s, that may be plugged into an
>> app.
>> Imagine a developer implementing a LoginModule. Reading through the
>> spec, s/he gets no clue s/he must free up resources in login().
>> I bet most of existing LoginModule-s do not expect the second call of
>> login() after successful commit().
>> I did a quick and rough googling on "implements LoginModule" and also
>> quick-checked JBoss srcs.
>> Surely, in no way this may be considered as a relevant research,
>> but from what I see - no one frees anything in login().
>> So again, my point is what a call of LoginModule.login() on already
>> logged+commited LoginModule may easily introduce a resource leak when an
>> application works with a custom LoginModules.
> Understood, some occurrences are outside our control.  As you point out
> above, we shall be good citizens to the best of our ability.
> Regards,
> Tim
>> [1]
>> http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#login

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message