----- Original Message -----
From: "David Jencks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 19, 2001 5:55 PM
Subject: Re: [JBoss-dev] VirtualHosts, security and deployers
> > 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?
A virtual host would only have one security domain and a security domain may
be used by multiple virtual hosts. It makes sense to allow individual
services and components within a virtual host to override the security
domain.
It also makes sense to allow security domains to form domains of trust to
allow
for single sign-on or transparent principal/credential mapping between
security
domains.
> > > 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.
>
A client container is just one example. In three tier deployments of the
server
it is very likely that I would only want to allow access to resources
between
the tier2-tier3 interface(tier2 JDBC pool for a tier3 DB. The users and
credentials
for accessing the databas are likely to be unrelated to the tier1 clients.).
In short, if a resource is creating a network object that may need to
be secured it needs to externalize the address on which it binds the
network object and it needs to externalize any authentication, authorization
policies as well.
> > 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?
>
>
Yes, but the actual mapping is not configured in the mbean descriptor. It
is a by-product of the JAAS login modules associated with the security
domain. The same for user to password or credential mapping. None of
this info should be in the JBoss configuration files.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
