You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Martin Vysny <mv...@whitestein.com> on 2008/09/03 13:46:06 UTC

Custom JAAS LoginModule: Principal with empty name provided

Hello guys,
  we tried to supply our custom JAAS LoginModule to OpenEJB. It works
beautifully, I have just one question.
When the OpenEJB is created (using the new InitialContext(properties)
construct), it invokes this LoginModule and the handler supplies an
empty string as an username in NameCallback. This isn't surprising
though: I do not provide any username nor credentials to the
InitialContext. What should I do?
- should I expect empty string in LoginModule and throw LoginException?
- or should I provide some username/password? This is probably rather
weird as no ejb method is being called...

Thanks!
Martin

ps: please see attached stack trace for quick reference.

Re: Custom JAAS LoginModule: Principal with empty name provided

Posted by Martin Vysny <mv...@whitestein.com>.
On Thu, 2008-09-04 at 10:37 -0700, David Blevins wrote:
> That's pretty much right.  The exact code looks like this:
> 
>          try {
>              // Perform a login attempt (which should fail)
>              // simply to excercise the initialize code of any
>              // LoginModules that are configured.
>              // They should have a chance to perform any special
>              // boot-time code that they may need.
>              login("","");
>          } catch (Throwable e) {
>          }
> 
> We can probably create a flag you could set to disable that behavior  
> if you'd rather not get the call.
> 
> -David
> 

Thanks for your response. I don't think there is need for this special
property: the valid LoginModule implementation will simply throw
LoginException on empty user so it's okay. I'll just turn off logging
for this special case ;)
Thanks!
Martin

> 
> On Sep 4, 2008, at 9:44 AM, Dain Sundstrom wrote:
> 
> > IIRC, OpenEJB performs a single "fake" login after installing the  
> > security service in an effort to cause the login module to  
> > initialize early.  The security service performs this in a try catch  
> > that ignores any exceptions.
> >
> > -dain
> >
> > On Sep 3, 2008, at 6:46 AM, Martin Vysny wrote:
> >
> >> Hello guys,
> >> we tried to supply our custom JAAS LoginModule to OpenEJB. It works
> >> beautifully, I have just one question.
> >> When the OpenEJB is created (using the new InitialContext(properties)
> >> construct), it invokes this LoginModule and the handler supplies an
> >> empty string as an username in NameCallback. This isn't surprising
> >> though: I do not provide any username nor credentials to the
> >> InitialContext. What should I do?
> >> - should I expect empty string in LoginModule and throw  
> >> LoginException?
> >> - or should I provide some username/password? This is probably rather
> >> weird as no ejb method is being called...
> >>
> >> Thanks!
> >> Martin
> >>
> >> ps: please see attached stack trace for quick reference.
> >> <stacktrace.txt>
> >
> >
> 
> 
-- 
Mgr. Martin Vysny | mvy@whitestein.com
Software Engineer
Whitestein Technologies s.r.o | www.whitestein.com
Panenska 28 | 811 03 Bratislava | Slovak Republic
Main +421 2 5443-5502 | Direct +421 2 5930-0717


Re: Custom JAAS LoginModule: Principal with empty name provided

Posted by David Blevins <da...@visi.com>.
That's pretty much right.  The exact code looks like this:

         try {
             // Perform a login attempt (which should fail)
             // simply to excercise the initialize code of any
             // LoginModules that are configured.
             // They should have a chance to perform any special
             // boot-time code that they may need.
             login("","");
         } catch (Throwable e) {
         }

We can probably create a flag you could set to disable that behavior  
if you'd rather not get the call.

-David


On Sep 4, 2008, at 9:44 AM, Dain Sundstrom wrote:

> IIRC, OpenEJB performs a single "fake" login after installing the  
> security service in an effort to cause the login module to  
> initialize early.  The security service performs this in a try catch  
> that ignores any exceptions.
>
> -dain
>
> On Sep 3, 2008, at 6:46 AM, Martin Vysny wrote:
>
>> Hello guys,
>> we tried to supply our custom JAAS LoginModule to OpenEJB. It works
>> beautifully, I have just one question.
>> When the OpenEJB is created (using the new InitialContext(properties)
>> construct), it invokes this LoginModule and the handler supplies an
>> empty string as an username in NameCallback. This isn't surprising
>> though: I do not provide any username nor credentials to the
>> InitialContext. What should I do?
>> - should I expect empty string in LoginModule and throw  
>> LoginException?
>> - or should I provide some username/password? This is probably rather
>> weird as no ejb method is being called...
>>
>> Thanks!
>> Martin
>>
>> ps: please see attached stack trace for quick reference.
>> <stacktrace.txt>
>
>


Re: Custom JAAS LoginModule: Principal with empty name provided

Posted by Dain Sundstrom <da...@iq80.com>.
IIRC, OpenEJB performs a single "fake" login after installing the  
security service in an effort to cause the login module to initialize  
early.  The security service performs this in a try catch that ignores  
any exceptions.

-dain

On Sep 3, 2008, at 6:46 AM, Martin Vysny wrote:

> Hello guys,
>  we tried to supply our custom JAAS LoginModule to OpenEJB. It works
> beautifully, I have just one question.
> When the OpenEJB is created (using the new InitialContext(properties)
> construct), it invokes this LoginModule and the handler supplies an
> empty string as an username in NameCallback. This isn't surprising
> though: I do not provide any username nor credentials to the
> InitialContext. What should I do?
> - should I expect empty string in LoginModule and throw  
> LoginException?
> - or should I provide some username/password? This is probably rather
> weird as no ejb method is being called...
>
> Thanks!
> Martin
>
> ps: please see attached stack trace for quick reference.
> <stacktrace.txt>