Re: Custom JAAS LoginModule: Principal with empty name provided
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. > >> > > > > > > -- Mgr. Martin Vysny | [EMAIL PROTECTED] 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 signature.asc Description: This is a digitally signed message part
Re: Custom JAAS LoginModule: Principal with empty name provided
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.
Re: Custom JAAS LoginModule: Principal with empty name provided
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.
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. 3:23:05,472 INFO [main service] Creating SecurityService(id=Default Security Service) javax.security.auth.login.LoginException: User '' doesn't exist at com.whitestein.abpm.security.DefaultAbpmLoginModule.login(DefaultAbpmLoginModule.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:579) at org.apache.openejb.core.security.SecurityServiceImpl.login(SecurityServiceImpl.java:71) at org.apache.openejb.core.security.SecurityServiceImpl.login(SecurityServiceImpl.java:33) at org.apache.openejb.core.security.AbstractSecurityService.login(AbstractSecurityService.java:97) at org.apache.openejb.core.security.SecurityServiceImpl.(SecurityServiceImpl.java:49) at org.apache.openejb.core.security.SecurityServiceImpl.(SecurityServiceImpl.java:36) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:673) at org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:268) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) at org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:49) at org.apache.openejb.assembler.classic.Assembler.createSecurityService(Assembler.java:1025) at org.apache.openejb.assembler.classic.Assembler.buildContainerSystem(Assembler.java:324) at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:250) at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:149) at org.apache.openejb.OpenEJB.init(OpenEJB.java:288) at org.apache.openejb.OpenEJB.init(OpenEJB.java:267) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.openejb.loader.OpenEJBInstance.init(OpenEJBInstance.java:36) at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:62) at org.apache.openejb.client.LocalInitialContextFactory.init(LocalInitialContextFactory.java:51) at org.apache.openejb.client.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:40) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.(InitialContext.java:197) ... snip ... signature.asc Description: This is a digitally signed message part