On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote:
> Date: Mon, 29 Jul 2002 13:19:25 -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:
>
> > I'd focus more on the 5.0 tree to do any major changes, though.
>
> Of course.
>
> > Are you talking about the UserDatabase global resource in 4.1? This is
> > actually a global thing, and not a Realm. See below for more.
>
> I just enabled the Http 'mbean' in mx4j, and I'm looking at the list of
> mbeans that are registered ( after a small change in modeler to make
> sure a single mbean server is created ).
>
> There are several objects:
>
> 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.
> One issue is that user databases and user/role can be specified per
> webapp ( at least in 3.3, I think 4.x have the same feature ). That
> means 'username=foo' can have different pass/roles in different webapps.
>
>
> The doc doesn't seem to cover the 'domain' part of the component
> names.
>
Yep ... in that sense it's incomplete. But, for now, just note that user
databases may or may not be shared by realms, and realms may or may not be
shared by contexts and hosts. No matter what combination you choose,
though, or how many user databases or realms you have (and, for realms,
where they are nested), there is always a well defined MBean name that is
both unique and (for realm nesting) lets you infer its scope of
applicability.
> I'll send a separate mail with comments on the 'local name' part.
>
>
> > Actually, a Realm is an illustration of how the current scheme actually
> > does disambiguate between these three cases. The MBean for a Realm can
> > have any of the following names, depending on where it's nested:
> >
> > catalina:type=REALM,engine=Standard
> >
> > catalina:type=REALM,host=www.hostname.com,engine=Standard
> >
> > catalina:type=REALM,path=/context-path,host=www.hostname.com,engine=Standard
>
> I know this.
>
> My question is if it would be better to use a different 'domain' for
> each webapp:
>
> 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?
>
> > These attributes specifically refer to the UserDatabase object that is
> > defined in the global resources in 4.1 (and JWSDP). One or more objects
> > of this type may indeed exist (with unique names), and the user/group/role
> > objects associated with them all have unique mbean names that includes the
> > identifier of the owning UserDatabase.
>
> So you're saying that 'user' is global, i.e. if tomcat is included in a
> J2EE container ( or another application ) it is expected that both will
> use the same mbeans ?
>
The "Users" domain, more precisely, is used for all the resources of the
"org.apache.catalina.UserDatabase" that appear in the
<GlobalNamingResources> section of server.xml. The "name" attribute of
the <Resource> entry becomes the "database=xxxxx" parameter in the
MBean name.
> 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 ).
>
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.
* 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.
>
>
> > Note that a Realm for a particular engine/host/context may or may not
> > actually use one of the UserDatabase things -- the only Realm
> > implementation that does is UserDatabaseRealm. If you are using
> > MemoryRealm, JDBCRealm, JNDIRealm, etc. there are no mbeans for the users
> > themselves (and you can't maintain the user database through the admin
> > tool).
>
> Why not ?
>
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.
> 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.
>
> > > My proposal would be to use:
> > > - 'tomcat' - for all 'server level' components ( including global Realm
> > > and User)
> > >
> >
> > I don't see why you'd change "catalina" to "tomcat", but that's pretty
> > trivial in the big picture.
>
> Catalina is fine.
>
> I was thinking of a domain per webapp and one domain for the container -
> i.e. coyote/jk + catalina + jasper.
>
>
> > I do think that you misunderstand the global-ness of users -- they are not
> > in the same hierarchy.
>
> I think I misunderstand it - and I still do :-)
>
> Can you clarify a bit ? Can you still have the same user name with
> different roles/pass in different applications, and how does this reflect
> in the Users: domain.
>
> And what's the relation between the Users: and the realms - if I have a
> JDBCRealm I suppose no Users: will be visible.
>
> Is any reason to treat the memory realm differently ?
>
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.
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.
But it clearly could have been done that way.
> > Take a look at the document referenced above, and you'll see how the
> > current naming scheme completely deals with the entire Catalina object
> > hierarchy. Then, we can talk about changes.
>
> I'll try to understand it better and send separate comments.
>
> Costin
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
