On Mon, 29 Jul 2002, Craig R. McClanahan wrote: > 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:
This is a bit confusing ( i.e. mixing 'realm' and 'user database' ), but I understand the idea and I like it. Let me see if we are talking about the same thing: - Tomcat should delegate all user-management stuff to a 'commons-user', based on UserDatabase, Role, Group, User. - Each webapp will be associated with one ( or more ) UserDatabases. A UserDatabase can be used by one or more webapss ( and other applications). - Realm interface will remain (for backward compatibility). - User databases are considered a separate space I'm ok with that - assuming everyone else is ( Nacho spent a lot of time on auth and realms - I would like to hear his opinion ) > 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. I think that has to change for 5.0. In fact a lot in the intialization should change - including making more intialization in background or on demand ( user is one simple thing that can be delayed ). The startup time is still to big IMHO, and loading 1000+ users in memory is not going to help. > Regarding competition over the domain name itself, that seems to be a > global issue for all JMX-enabled applications. If we plan to eventually move to commons and keep it independent of tomcat - than Users: domain is better. If it is specific to tomcat, we should use the same domain. > > 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. I don't think DefaultContext allows this flexibility - it would be more like a ContextGroup or multiple default contexts... > Not unless we go modify those realms to know about users/roles/groups, or > build JDBCUserDatabase and JNDIUserDatabase. Either approach is feasible. I prefer the second, and make all this a separate component ( eventually later move it to commons ). The realms should remain only for backward compat. > Agreed. Like everything, we implemented what we needed for now :-). As long as the interfaces don't freeze before we are sure that things that we'll need in future can be implemented, it's fine :-) > > > 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 was asking about the actual API - especially wrt managing large databases of users. The latter is a far better idea IMHO ( including at this time ). > 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. Yes. But we should first define a UserDatabase interface that can deal with many users and not-in-memory. > 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). Yes, both by 'filter' and by id. For example if we display the users in a page, 50 at a time we should be able to iterate in groups of 50 - and register/unregister those beans on demand. The problem is that the model may not work very well as performance ( there are notifications, and some overhead on adding mbeans ). We certainly need a 'user cache' with the most recently used users ( for both jndi and jdbc ), but if each user will have an mbean - it's a different question. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
