> -----Original Message----- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > > I have a concern about how we locate and instantiate the LoginModules > defined in a JAAS Configuration. The scenario I have if from the > JMXConnector when it is trying to authenticate a remote JMX invocation. > It does this by taking the supplied username and password and login in > via JAAS: > > LoginContext context = new LoginContext(configName, credentials); > context.login(); > return context.getSubject(); > > The LoginContext gets the Configuration, locates the > AppConfigurationEntry and then loads the LoginModules using the thread > context classloader. > > Which classloader is this? > > I can set it to the one for the Geronimo Configuration that contains the > JMXConnector. This will work if all the login modules are on its > classpath, i.e. are in the Configuration defining the JMXConnector or a > parent. > > However, the connector could be configured to use a LoginModule defined > by a child configuration, or by a niece (child of sibling > configuration). In that case, the LoginContext will not be able to > locate the module and authentication will fail. > > This may not be common for JMX but I think it is likely for EJBs, EARs > etc. that LoginModules could be deployed with the application and so > would be located in a child classloader. > > Do we want to allow this or is it too much of a security hole?
I don't see how it could be a security hole. If you can start a configuration, then you can pretty much do anything you want, no? Or are we saying that there are scenarios where untrusted clients can start a Geronimo server which has been configured by a trusted admin and stored on a trusted configuration server? > If we do, I think we may need to have a special LoginContext or wrapper > module that can delegate to the appropriate children. > > Alan, David J, I think you talked about this at some point - is it > solved and if so how? I don't think that David J and I talked about this. Regards, Alan
