----- 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.
> 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.
> > 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.
> >
> > 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.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
