avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Re: Merlin Queries]
Date Sat, 24 Aug 2002 13:18:59 GMT


Shekhar Jha wrote:

>Thanks for the answer! Hope you had a good sleep.
>

I did!

>Stephen McConnell <mcconnell@apache.org> wrote:
>  
>
>>Shekhar Jha wrote:
>>
>>    
>>
><Snip>
>  
>
>>>2. 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
>>>      
>>>
>if
>  
>
>>>container classloader CLASSPATH are defined so that the classpath of the
>>>      
>>>
>child
>  
>
>>>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 X

What 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>
>
>  
>
>>>4. Why is stage tag needed when it is the LifeCycle handler that needs to
>>>      
>>>
>know
>  
>
>>>about the interfaces and those interfaces would be implemented by the
>>>component?
>>>
>>>      
>>>
>>The <stage/> tag declares a component's dependency on an extension
>>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:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message