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
3. Next step is to make a facility which provides the JAAS style subject level
security
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).
The equivalent "factory" in Merlin is the DefaultSystemContext class under the composition/impl package. It's basically the single point of reference for all system related information.
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) and replaces the policy for the entire JVM.
Sounds good - personal preference is to work closely with the Apache Directory Project to leverage Eve (an LDAP server) for management of identifies, credentials, attributes, etc.
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.
Absolutely yes - components have very different concerns relative to the kernel. Kernel is much more related to environment and system policy, whereas a component is much closer to application context.
Not only the authorization model may be different, but also each component
may want to use a different authenticator.
This sentence worries me a bit. Given the following two possible approaches:
(a) component implementation does authentication
(b) or, component model does authentication prior to delegation
to component implementationI'm assuming case (b) - which is consistent with everything else in Merlin - i.e. from a component implementation point of view "if it happens its ok - if it doesn't happen - there's a good reason". What I mean is that a component implementation should not need to worry about authentication - instead it should declaring any specific assumptions with its type definition. Based on this, together with deployment directives we should be able to handle authentication inside the component model and runtime on behalf of the component instance.
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.
This was the initial approach that Nicals and I stated off with but there is a problem. The cascading container model deals explicitly with the management of classloaders, class visibility (and isolation). While its convenient to think about the container hierarchy as a structure for other things - its basically nailed down relative to the classloader management model.
Instead - I'm moving away from this toward an different model in which policies are expressed in a different model that is applied to a component hierarchy via a map.
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.
My feeling is that the usage of codesource as a mechanisms to implement a policy is the wrong approach (but I could easily be wrong).
To me a codesource does not let me distinguish things in terms of the usage of a component (or more specifically - the functional contribution of the component in a system) as opposed to attributes of a class. That functional contribution should be declared independently of the code-source. At runtime I would need to consolidate component policy with codesource policy prior to granting a permission.
In the longer term I see this as a general approach - plugable permission schemes --> scheme aggregation --> access decision.
Cheers, Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
