On 2001.09.19 19:43:34 -0400 Scott M Stark wrote:
>
> ----- Original Message -----
> From: "David Jencks" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 19, 2001 3:50 PM
> Subject: Re: [JBoss-dev] VirtualHosts, security and deployers
>
>
> > Hi,
> > This is great!
> >
> > I have some questions...
> >
> > As I understand it a virtual host is an ip address (+ port?)
> Just an IP address and maybe a name. The name may not resolve
> to the IP address if the interface on which a service is bound is
> behind a NAT firewall. The services associated with the virtual host
> will have ports.
>
> > 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.
> >
> Correct. It is a logical grouping of users, roles, a KeyStore(certs,
> private
> keys,
> secret keys), permissions, etc.
>
> > 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?
> >
> A security domain is really a passive property that is available to the
> services
> within the domain. The only point at which a security domain and virtual
> host
> have a relationship is if the domain was using SSL/TLS and needed a
> server
> certificate that used the virtual host DNS name in order for SSL clients
> to
> see a valid certificate. Other than that the virtual host and security
> domain are
> really independent.
So you are saying each virtual host can have or use many security domains
and each security domain can be used by many virtual hosts? Whereas a
particular application has to have one virtual host and one security
domain?
>
> > 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?
> >
> I can see it going that way if you want the services in a domain to be
> isolated
> from other domains. Users trying to use JBoss for ISP hosting definitely
> would
> like that property. In that case the Application MBean would have a class
> loader
> that simply isolated the application resources from other domains. Java2
> permissions
> can also be associated with the domain level class loader.
>
> >
> > 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?
> >
> I can think of many. JDBC connections when we start offering client
> containers, JMS
> connections, etc. Basically any managed connection may need to be made
> available
> only on the virtual host interface.
hmm... I was kind of thinking a client container could be a mini-jboss with
a client deployer and its own ConnectionFactoryLoaders...and very little
else.
>
> > > 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.
> >
> The SecurityDomain configuration would show up in a mbean along with
> the corresponding JAAS login configuration info. I removed the security
> related config from the ConnectionFactories as this would be delegated to
> the SecurityDomain object.
So you are proposing (in psued0 mbean-xml)
<security-domain>
...
<principal-mapping-config>
...
<connection-factory-ref1/>
<connection-factory-ref2/>
</principal-mapping-config>
<principal-mapping-config>
...
<connection-factory-ref3/>
<connection-factory-ref4/>
</principal-mapping-config>
</security-domain>
rather than
<security-domain>
...
<principal-mapping-config>
...
</principal-mapping-config>
<principal-mapping-config>
...
</principal-mapping-config>
</security-domain>
<connectionfactoryloader>
...
<principal-mapping-ref/>
</connectionfactoryloader>
The second avoids mapping several principal mappings to one connection
factory. Offhand, I can't think of a way it would make sense to have more
than one principal mapping/connection factory, can you?
>
> > >
> > > 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.
> >
> This is really all am I thinking about. The only reason there is a
> physical
> application
> mbean at all is to parse the domain configuration, establish the class
> loader and propagate
> the virtual host and security domain to the contained mbeans. This logic
> could be simply
> made a part of the 2.4 ConfigurationService and the equivalent 3.0
> object.
>
> > >
> > > 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?)
> >
> Yes, I would expect so. Effectively there would be an enterprise domain
> context(EDC)
> java:domain/env or the like that would be the root of the application
> domain
> namespace.
>
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
