geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "hbaxmann" <>
Subject AW: Which classloader should be used by LoginContext when loading modules?
Date Sat, 05 Jun 2004 18:13:45 GMT
> > 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. 

OTOH, JSEF could handle this 'on-behalf-of' issue by configuration.


> > 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

View raw message