> -----Original Message----- > From: Nader Aeinehchi [mailto:[EMAIL PROTECTED] > 1. Merlin's Kernel is pretty limited, and not really worth adding any > security > > features, since the same can basically be done by the > java.security.policy > > file. > > 2. The interesting parts lies in the possibility to assign grants to > 'components' > > instead of codebases
Still the same thing except your using the component's set of classes as the code base specifier instead of using a package based specifier. But it is a very convenient feature I agree we should have it. > 3. Next step is to make a facility which provides the JAAS style subject > level > > security Yep we might need to sprinkle a little bit of JAAS and JACC into this. Personally I find Java security appalling and it does slow things down. I do recommend that the ability to control security be on the level of service methods like EJB in a way so it's not on all the time in places where you don't need it to be. It might just however be better to just use a general security mechanism free of all this crap so we don't run into conflicts when the container is embedded into a J2EE container. > For a customer, I developed a security service that incorporated security > in > kernel (a factory would decide whether to start in security mode or not). > This secure kernel is build on JAAS, also both codebase and subject as the > secure kernel at boot reads the policy file (say from a database or a > ldap) I like the LDAP idea :-) > and replaces the policy for the entire JVM. > Furthermore, I developed an extended security manager that could provide > addon features like method permission (similar to EJB declarative method > permission) etc. One point I learnt from this project is that the > underlying "components" may have a different security model than the > kernel. > Not only the authorization model may be different, but also each component > may want to use a different authenticator. Based on that experience, I > got > the idea that a cascading security model should be provided, in which each > component has its own security model that cannot violate the security > constraints imposed by its surrounding container. > > The other thing I learnt was not to differentiate/favourize codesource > with > subject. After all, security is about WWW (Where codesource, Who subject, > What guarded resource). > > Regarding "assign grants to 'components' instead of codebases", I would > think you can solve it by a special purpose classloader. When a component > is loaded by the classloader, simply assign the component its own > codoesource, that is different from its physical codesource. A similar > approach is taken in Sun's J2EE 1.3 reference application server. > Nadar this is all great stuff. You should be working with us to bring this about. Personally I'm working on an embeddable LDAP server based on Merlin which I'm hoping can be incestuously reused for the security backing store of Merlin as well as other containers even EJB servers. Perhaps we can discuss this. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
