On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote:
> Date: Mon, 29 Jul 2002 14:15:52 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: [5.0 - config] jmx names, part 1: domains
>
> On Mon, 29 Jul 2002, Craig R. McClanahan wrote:
>
> > > Users:type=Role,rolename=admin,database=UserDatabase
> > > Users:type=User,username=both,database=UserDatabase
> > > Users:type=UserDatabase,database=UserDatabase
> > >
> >
> > Yep ... the document only covers the "Catalina" names at the moment.
> >
> > In the three you cited above, the "database=UserDatabase" part of the name
> > is the common link that this role and user belong to the same database of
> > users.
>
> In other words we'll have:
> Users: type=User, username=foo, database=myHost.com/myWebapp
>
Specifically, the "database" attribute of the object name for a user comes
from the "name" attribute of the <Resource> defining that user database.
> Or database=myAppDatabase and a separate definition associating it
> with a separate webapp ?
>
In the current implementation, the association of webapps to user
databases is *indirect* by virtue of the Realm that is used. You can
share a single user database across webapps, if you want to, in a couple
of different ways:
* Share a single <Realm>, connected to a single UserDatabase,
at the engine or host level (that's what the default server.xml
file does to make users effectively global)
* Create a <Realm> element for each webapp (inside the <Context>
element), but use the same "resourceName" value for each.
On the other hand, you can force *not* sharing by having multiple
UserDatabase resources, and having a <Realm> for each webapp that uses
different resourceName values.
> In any case, the problem remain:
> - is this a 'global' thing that other apps will use ( i.e. no conflict
> on the User domain ) ?
> - how does it relate with JDBC and other realms where you don't want
> all users loaded in memory.
>
The current admin webapp assumes that all users/roles/groups will be
loaded, so it would need to be refined as well as the strategy for
creating these mbeans only at startup time.
Regarding competition over the domain name itself, that seems to be a
global issue for all JMX-enabled applications.
>
> > > myApp:type=REALM,...
> > >
> > > I'm not sure this is a good idea or not - the benefit would be to
> > > eventually control the access to the app by domain ( but that can be done
> > > by name ) or allow better grouping.
> > >
> >
> > What happens when you want to share a realm across all the webapps on a
> > virtual host, or all webapps across all hosts?
> >
> > What happens when you have webapps named "myApp" on different virtual
> > hosts so you have to disambiguate the domains?
>
> myApp would be host/path combination.
>
> But the more interesting question is what to do if you want a group
> of (web)applications sharing the same domain.
>
We have a variation of that concept in the actual managed components as
well -- DefaultContext.
> There is also JSR77 which is not very clear on the domain, but does
> have a different 'granularity'.
>
> Well, I'm fine with a single domain and having all the hierarchy in
> the name, it may be simpler.
>
>
> > > That may be an excelent solution - as long as it is still possible to have
> > > users that are specific to webapps. ( i.e. have host, path in the user
> > > name ).
> > >
> >
You can.
> > It is, in at least two different ways:
> >
> > * Establish more than one UserDatabase resource with different
> > "name" attributes (and therefore different MBean names). Connect
> > the <Realm> for your webapp (or host, or engine) to the user database
> > you want for that realm. The default server.xml file has the following
> > nested inside the <Engine>, so it's shared -- but you could just as
> > easily have it nested in a <Host> or <Context>:
> >
> > <Realm className="org.apache.catalina.realm.UserDatabaseRealm
> > resourceName="java.UserDatabase"/>
> >
> > where the "resourceName" parameter links you to the particular
> > UserDatabase resource instance you want this realm to talk to.
>
> But this won't work with the other realms ( JDBC and so on ).
>
Not unless we go modify those realms to know about users/roles/groups, or
build JDBCUserDatabase and JNDIUserDatabase. Either approach is feasible.
>
> > * Use one of the other <Realm> implementations (JDBCRealm and so on),
> > at the cost of not having MBeans for these users and therefore not
> > being able to use the current admin webapp to manage them.
>
> IMHO the clear-password, plain-xml-file is nice for example but it's
> not very practical for production.
>
> So the intersting problem is what we do about JDBCReam and so on,
> and how can the admin manage that.
>
> I don't see any reason why the admin wouldn't be able to support
> a JDBCRealm - or why we would treat user database differently.
>
>
> > It would be easy to write a JDBCUserDatabase implementation (backed by a
> > database) or a JNDIUserDatabase implementation (backed by an LDAP server)
> > to go along with the existing MemoryUserDatabase implementation (backed by
> > the conf/tomcat-users.xml file). If this were done, you would then be
> > able to manage the users with via the Admin webapp -- which does all its
> > manipulations of these users via the mbean attributes and operations.
> > The UserDatabase, User, Group, and Role APIs are all interfaces.
> >
> > Nobody has done this yet, though.
>
> If we were to have a single model for all, then User mbeans will
> eventually be created on-demand ( and removed from the mbean
> server to not overload it ). Say you have 1000+ users, the
> Realm mbean can expose a method 'list()' or 'find()' with
> some params to limit the number of users that are extracted.
> The Realm will create mbeans and the admin will display/edit
> them.
>
> The only problem is that the model of having all Users with
> an MBean in the Users: domain doesn't work - a real user database
> can have a lot of users and reading all of them and registering
> doesn't scale.
>
Agreed. Like everything, we implemented what we needed for now :-).
> > > The Realm can have a method 'list users' or 'find user' - and it can
> > > register or create User object dynamically. I see no reason why the same
> > > interface that is used for memory can't apply to a JDBC realm ( assuming
> > > we add the insert statements )
> > >
> >
> > It could have been done that way as well, but it seemed better to provide
> > a DAO type pattern for accessing this stuff.
>
> Not sure what you mean here - can you expand ?
>
When faced with the requirement to add "web-administratable users" for
JWSDP, there were two fundamental approaches we could have taken:
* Expand the responsibility of the Realm interface beyond just
the authenticate() and hasRole() methods
* Treat a "user database" like you would any other sort of data
in a database-enabled (or EJB-backed) application, and create an
abstraction for the notions of creating, modifying, and removing
users/groups/roles.
The latter seemed like a better idea at the time, for the reasons
discussed further below.
>
>
> > I wanted it to be possible to write applications that managed user
> > databases with zero references to the rest of Catalina's APIs, so created
> > the UserDatabase/Group/Role/User family for that purpose. Part of the
> > thinking is that this could be easily extracted out into a commons project
> > for managing "user databases" -- and for that, the less interdependence
> > the better.
>
> That's not a bad idea, +1.
>
> The only problem is making sure we get JDBC/JNDI/JAAS UserDatabases
> (eventually by using the current Realms ) with read/write capability.
Definitely need to cover JDBC/JNDI/JAAS/etc. technologies for user
databases.
Fortunately, if we go this way, we won't actually have to touch
UserDatabaseRealm at all (until we modify the interfaces, of course). And
then, it's only one Realm implementation to mess with, that can talk to
any of the UserDatabase implementations.
>
> Tomcat will then just have a reference from a context to a user database.
>
> It's fine with me as idea, but not sure about the API of UserDatabase.
> ( in the context of 1000+ users )
>
> Nacho - what do you think ?
>
One thing that will definitely be needed is a way to select a subset of
all the users/roles/groups (basically, the "finder method" concept of
entity beans).
>
> > Adding the notion of users/groups/roles directly into a Realm also will be
> > perceived by some as too restrictive. There are lots of different ideas
> > on the set of properties that belong on a "user" in the database. Keeping
> > it from the Realm's sole responsibility to authenticate and authorize
> > users for Tomcat also seemed cleaner.
>
> If other apps are going to use the user mbeans - it make sense and is much
> better this way.
>
> Should we try to separate the users/ code and UserDatabase, etc - first
> as a tomcat-5 component ( same level with jasper/catalina ), maybe later
> move it to catalina ?
>
> ( not now - sometime in the next few months :-)
>
> Costin
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
