Hi,
This is great!
I have some questions...
As I understand it a virtual host is an ip address (+ port?)
A security domain is an authentication/authorization mechanism (instance),
and something is within a security domain if it uses that instance for its
authentication/authorization.
In your scheme are the virtual hosts and security domains coextensive? (do
they partition the set of components identically)?
Do the security domains form a sub-partition of the virtual hosts? vice
versa? are they independent?
And for me the biggest question - how does this relate to classloaders?
So... if virtual host = security domain, do we also have a classloader
(ServiceLibrary/Scope type thing) for it? Is this the same as the
application classloader or is it the parent classloader of the application
classloader?
More comments interspersed.
On 2001.09.19 16:50:56 -0400 Scott M Stark wrote:
> I've been looking at how to include virtual hosts for wars, ejbs and rars
> that need to bind their exported interfaces to specific addresses. Also
> needed
> is a notion of a security domain for the KeyStore if you need to use
> SSL/TLS
> with
> the exported transport. The security domain could also be used for
> authentication
> and authorization of users, principal mapping, single sign-on, etc.
Certainly an rar needs some security support, but what interface would one
export that is bound to an address?
>
> Right now there are serveral notions of deployers, not all of which are
> well
> defined by an interface. There is a base DeployerMBean that is
> implemented by the J2eeDeployer and RARDeployer, but it is not used by
> the
> EJB deployer(ContainerFactory) or the WAR deployers(EmbeddedTomcat,
> EmbeddedJetty).
> Rather there is an assumption about the signature of deploy made by the
> J2eeDeployer
> for the JarDeployerName and WarDeployerName mbeans it uses. There is also
> no
> unified notion of security at the deployer level. EJBs and WARs based
> security off of
> jboss.xml and jboss-web.xml descriptors. RARs have another notion of
> security
> at the ConnectionFactoryLoaderMBean level.
>
> I would like to come up with an application domain notion that combines
> all
> deployers,
> auto deploy directories, virtual host interface and security into a logic
> collection of
> resources and application components with a common interface address and
> security
> domain. Effectively all of the mbeans in an application domain become
> contained
> mbeans within the application domain. For example,
>
> <mbean code="org.jboss.deployment.J2eeApplication"
> name="Default:service=J2eeApplication">
> <attribute name="DomainName">Default</attribute>
> <attribute name="VirtualHost">localhost</attribute>
> <attribute name="SecurityDomain">java:/jaas/localhost</attribute>
> <attribute name="JarDeployerName">:service=ContainerFactory</attribute>
> <attribute name="WarDeployerName">:service=EmbeddedCatalina</attribute>
> <attribute name="RarDeployerName">:service=RARDeployer</attribute>
>
> <mbean code="org.jboss.ejb.ContainerFactory"
> name=":service=ContainerFactory">
> <attribute name="VerifyDeployments">true</attribute>
> <attribute name="ValidateDTDs">false</attribute>
> <attribute name="MetricsEnabled">false</attribute>
> <attribute name="VerifierVerbose">true</attribute>
> <attribute name="BeanCacheJMSMonitoringEnabled">false</attribute>
> </mbean>
> <mbean code="org.jboss.catalina.EmbeddedCatalinaServiceSX"
> name=":service=EmbeddedCatalina" >
> <attribute name="WebAppsRoot">webapps</attribute>
> </mbean>
> <mbean code="org.jboss.resource.RARDeployer"
> name="JCA:service=RARDeployer" />
>
> <mbean code="org.jboss.resource.ConnectionManagerFactoryLoader"
>
> name=":service=ConnectionManagerFactoryLoader,name=MinervaNoTransCMFactory">
> <attribute name="FactoryName">MinervaNoTransCMFactory</attribute>
> <attribute name="FactoryClass">
> org.jboss.pool.connector.jboss.MinervaNoTransCMFactory
> </attribute>
> <attribute name="Properties"></attribute>
> </mbean>
>
> <mbean code="org.jboss.resource.ConnectionFactoryLoader"
> name="JCA:service=ConnectionFactoryLoader,name=MinervaDS">
> <attribute name="FactoryName">MinervaDS</attribute>
> <attribute name="RARDeployerName">:service=RARDeployer</attribute>
> <attribute name="ResourceAdapterName">
> Minerva JDBC LocalTransaction ResourceAdapter
> </attribute>
> <attribute name="Properties">
> ConnectionURL=jdbc:HypersonicSQL:hsql://localhost:1476
> </attribute>
> <attribute name="ConnectionManagerFactoryName">
> MinervaSharedLocalCMFactory
> </attribute>
> <attribute name="ConnectionManagerProperties">
> # Pool type - uncomment to force, otherwise it is the default
> #PoolConfiguration=per-factory
> # Connection pooling properties - see
> # org.jboss.pool.PoolParameters
> MinSize=0
> MaxSize=10
> Blocking=true
> GCEnabled=false
> IdleTimeoutEnabled=false
> InvalidateOnError=false
> TrackLastUsed=false
> GCIntervalMillis=120000
> GCMinIdleMillis=1200000
> IdleTimeoutMillis=1800000
> MaxIdleTimeoutPercent=1.0
> </attribute>
> </mbean>
>
> <mbean code="org.jboss.ejb.AutoDeployer" name=":service=AutoDeployer">
> <attribute name="Deployer">:service=J2eeApplication</attribute>
> <attribute
> name="URLs">../deploy/default,../deploy/default/lib</attribute>
> </mbean>
> </mbean>
>
> All services within a J2eeApplication domain would inherit the
> J2eeApplication domain
> name as their JMX ObjectName domain component. All services would be
> associated
> with the security domain of the J2eeApplication domain.
OK, but haven't you left out the configuration of the security domain? For
instance, the ConnectionFactoryLoader security stuff seems to have
disappeared. I don't see right off how you could easily separate principal
mappings from their ConnectionFactories-- it seems to me that one
application might use 5 ConnectionFactories each with an incompatible
PrincipalMapping.
>
> A similar domain notion would need to be added to the 3.0 RH services
> configuration.
>
> An alternative is to simply add VirtualHost and SecurityDomain notions to
> the
> common ServiceMBean interface for example, and use naming conventions to
> achieve the same effect.
I think being able to deploy/undeploy sars or *service.xml into a
preexisting VirtualHost/SecurityDomain is desirable. How about having a
"universal deployer" that sets up the VirtualHost/SecurityDomain, that must
be deployed first, and then anything it allows (services, rars, ears, wars,
whatever) can be deployed into it based on their VirtualHost/SecurityDomain
attributes. Having the mbeans separate rather than enclosed seems to me
offhand as if it would make immediate and delayed deployment more similar
and simpler. On the other hand...Enclosing the sets of mbeans in one
element provides a convenient "set" of mbeans to deploy together in the
configure/init/start cycle. How about... the enclosing element just
specifies the domain, virtual host, and security domain, and all the
deployers are contained mbeans? Then you can require that all mbeans be in
an enclosing element, which defines a deployment set.
>
> Another alternative is to have multiple instances of JBoss running, one
> for
> each
> domain with the configuration name defining the domain with a
> multi-domain
> launcher.
>
> I'm looking for comments and suggestions on how to do this.
Would each application have its own jndi namespace? (internally the app can
only see its own jndi stuff, externally you go to 1099 on the virtual host
ip address and deal with its security?)
Thanks!
david jencks
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
