> > 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? >
This is excatly a scenario for which I would provide the secure pot: to heave the security border more up the levels, inside the server, so we are not dependend on operating system security. Yes, one may have secure islands inside a unsecure architecture with unsecure components inside. Makes additional/subtractive permissions necessary. 'Java Secure Execution Framework' JSEF is my current rule of thumb. http://www.infosys.tuwien.ac.at/jsef/ OTOH, JSEF could handle this 'on-behalf-of' issue by configuration. bax > > 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 >
