Shekhar Jha wrote:
Thanks for the answer! Hope you had a good sleep.
I did!
Stephen McConnell <[EMAIL PROTECTED]> wrote:
<Snip>Shekhar Jha wrote:
if2. What is difference between library tag and classpath tag? Would it have
provided a better facility if the library would have been available to
container and its children while classpath would have been specific to the
container itself. This may be important in cases for example of usage of
different SSL libraries by the container. I think this requirement is met
childcontainer classloader CLASSPATH are defined so that the classpath of the
---is prefixed to parent classpath. Is that how it is implemented?
On the <library/> tag:
Remember that the <library/> tag is just a collection of
directory paths that are used by the classloader to attempt
to locate extension jar files. When invoking addURL on a
URLClassLoader the URL is scanned firstly for required
extensions, and secondly for component types. If an jar
extension dependency is found - the system attempts to
resolve it using jars located in the library paths. I decided
not to make <library/> available at the container level simply
on the grounds that it keeps things a little simpler. That
could change in the future.
So the library tag is more for substituting the -Djava.extensions(NOT SURE) at
the command prompt ( for the Kernel and everything managed by it i.e.
containers.
Yep.
The <library/> element was called <extension/> but that conflicted with the term <extension/> used inside the Type DTD. I decided to call it library so that people wouold not get confussed.
On classloaders and the <classpath/> declaration:
The classloader system in Merlin is hierachical in nature. If
you look at the example kernel file for Berlin's project, you
will see the declaration of a classpath for the root container
in which Conerstone content is defined. Berin's stuff appears
in a subsidiary container where we add the supplimentary jar
file. Remember that the subsidiary container has access to the
classes and components declared in its parent container. Using
this approach you can better control the exposure of classes in a
system. For example, a container located at the same level as
Berin's container cannot access Berin's classes.
----- I am NOT sure whether this solves the problem that I am describing. Consider that there is a component/service that needs SSL library for setting up the connection. Let us assume sombody ships a container with a a very good SSL library but it does not have license to provide that to the clients. How does somebody stop the child container and its components have access to those classes. This is reason for a requirement to specify a container level CLASSPATH NOT available to its child.
You can prevent this by locating your SSL libraries in a sub-container.
I.e.:
container A
(contains component X service classes)
|
------------------------------------
| |
| |
container B1 container B2
(SSL lib classes) (component Y classes)
component X component Y using a service from XWhat you describing is the situation where you need to protect the SSL clases
but enable the publication of a component's services. Containers restrict access
to classes but federate services provided by components.
In the above example container B1 holds a set of protected classes that are not
accessible to anything but the components in B1. Container B2 holds a component
that is depedent on services from X, using classes published (shared) in
container A.
Don't try doing the above in a test just yet - Merlin handles the complete
resolution of components up the parent graph so that any services established
in an immediate or parent container are available as candidates for dependency
resolution - however - there is still work to do the cross-container federation
functionality. Container export of services is in place which means that cross
container export is achievable providing you manage this at a custom container
level (i.e. an extended DefaultContainer). I intend to include federation as
part of DefaultContainer but there are some policy questions I'm not yet
completely clear about and also, there are implications at the container
re-assembly level (in particular - if you stop a component the implication are
currently all downstream - but with federation the implications become a lot
more complex).
If this is of particular interest let me know and I could excalate the priority.
<snipped>
know4. Why is stage tag needed when it is the LifeCycle handler that needs to
-------The <stage/> tag declares a component's dependency on an extensionabout the interfaces and those interfaces would be implemented by the component?
handler that can handler a particular stage interface. If you look
at the <estension/> tag it declares the interface(s) it can support
(things like Exploitable, Demonstratable, etc.). The stage tag
declares the component's depnedency on a provider of Expliotable,
Demonstratable. When Merlin is assemblying a component it looks for
stage dependencies and then attempts to resolve them by locating the
best extension handler candidate within the type manager hierachy. This approach means that you can easily replace estension handler
implementations indepedently of the components the extension handles.
Did you have any practical case in mind. Because as I understand the stage and
extension handler are closely connected to each other and very specific the
application that is using it.
Nope. The handlers handle an stage interface. I.e. there is no strong associatation between a component and an extension.
Components may dependent on somerthing handling a stage interface.
An extension provides support for component with a particular stage interface.
The container mediates the two.
And the application/service/component MUST
specify how it should be handled. for example, Consider a component that
supports two interface Secured which generates a token and Persistable which uses this token to
authorize access to the database to load data. The Handler would be specific
to this application since it requires to call first Secured and then the
Persistable. It can not depend on a default handler to take care of that.
Lets look at this from the point of the view of the compoent that is both
Securable and Persistable. The component declares its dependency towards
a handler in its .xinfo file. Here is an example of the meta-info that would
declare the component's extension depedencies:
<type>
<component>
<name>just-a-demo</name>
</component>
<stages>
<stage>
<name>the-security-solution</name>
<reference type="Securable"/>
</stage>
<stage>
<name>the-persistence-solution</name>
<reference type="Persistable"/>
</stage>
</stages>
</type>All the above delcaration does is to declare that the componet has a depedency on an extension provider or providers that is capable of providing support for the Securable stage interface, and the Persistable stage interface. Merlin will attempt to locate a handler that publishes that fact that it can support an equivalent stage interface (Securable, Persistable, etc.).
Components that are capable of providing extension handling ability declare themselves to Merlin via the met-info in the .xinfo file in much the same way that the target component declares its dependecies. Here is an example of the .xinfo file for a component publishing the fact that it can provide Securable stage handling:
<type>
<component>
<name>just-a-demo</name>
</component>
<extensions>
<extension>
<name>a-security-solution</name>
<reference type="Securable"/>
</stage>
</stages>
</type>Note that in this example the component is declaring its ability to handle one of the two stages your concerned about. Merlin would continue and attempt to locate another component publishing the fact that it can support the Persistable stage interface. In the case where there is a direct association between two stages, you would probably define this as a single stage interface. The alternative is that the Securable is providing information to the component which the component uses during the Persistable phase (which sounds a little overly complex).
-----5. The document says that explicit profile over rides the packaged
configuration. But can this feature be used by a package/component user to
override security information specified in the package profile. Am I wrong or do we need a "final" directive as a part of the profile definition.
A profile is simply a <component/> declaration packlaged in an .xprofile file. The container handles the assignment of status to profiles as it creates them (actually, its the ContainerManager which is where all of the classpath management and classloading goes on). As such, there isn't a security risk related to a something inside a .xprofile. There is a security risk concerning implementation classes that are introduced - but this is much lower in Merlin than other containers due to the ability to isolate the class in the container hierachy.
Let us assume that there is a third party component that has private signer
key embedded in its xprofile ( or would you recommend that it be placed at
some other place)
Putting it in the xprofile is reasonable (as context directive, configuration or parameters value).
which If I understand correctly may be passed to the
component as part of the parameter phase. Now what happens if the assembler
over rides this information with its own private key so that hosting container
passes that information to initialize component resulting in invalid
authorization.
Interesting.
If the assembler defines a profile and adds in a particular key, then that's the key that will be used. There is now way (currently) to provent an assembler from overriding packaged profiles. Adding some sort of "sealed" attribute into the profile would not work because an implementation can always create an alternative configuration/parameters argument. However (speculative thinking mode) - if a type declared that it was only instantiatable from a packaged profile, and if the Merlin Type Manager validated that the profile was correctly signed relative to a hash contained in the type, then we are probably talking about a solution that would be validatable. Your component implemetation would need to verify that its working with a trusted container, and that its using a signed profile. I'm not immediately sure how this would be done as I've gone to rather a lot of effort to ensure that components do not need to know about the container they are running in (in fact componet cannot get a reference to the container they are hosted in).
I am not sure whether such thing is possible in Merlin ( Have not completed the code walk through). If it is then May be we MAY want to give component developer some additional facility to enforce that some parameters can not be over written by the assembler.
This sounds like a DMAS probem - you have to deal with a trusted container. Once you have a solution for placing trust in the container, the next question is proving the container with the policy concerning profiles models. In your example you need to be sure that the container corectly mediates the process taking into account policy that overrides an assembler directive. A possible approach would be to use an extension through which the sensitive information is provided by the container to the component based on resources declared in the profile - but this would would require something like a "sealed" attribute on an context entry parameter value declaration.
To get a better idea of what I'm talking about, take a look at the org.apache.excalibur.merlin.model package and in particular, the ContextDirective, Entry and Parameter classes.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
