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 Or database=myAppDatabase and a separate definition associating it with a separate webapp ? 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. > > 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. 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 ). > > > > 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 ). > * 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. > > 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 ? > 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. 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 ? > 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
