See below. On Mon, 12 Aug 2002, Jacob Hookom wrote:
> Date: Mon, 12 Aug 2002 22:09:11 -0500 > From: Jacob Hookom <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: [Q] Realms, Principals, et al... > > > > | -----Original Message----- > | From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > | Sent: Monday, August 12, 2002 9:27 PM > | To: Tomcat Users List > | Subject: RE: [Q] Realms, Principals, et al... > | > | > | > | On Mon, 12 Aug 2002, Jacob Hookom wrote: > | > | > Date: Mon, 12 Aug 2002 21:02:15 -0500 > | > From: Jacob Hookom <[EMAIL PROTECTED]> > | > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > | > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > | > Subject: RE: [Q] Realms, Principals, et al... > | > > | > | Just as a simple example, consider the concept of "group" that > many > | > | security environments define. Either of the following mappings > would > | > be > | > | perfectly legal from the perspective of a servlet container (or a > J2EE > | > app > | > | server): > | > | > | > | * "Group == Role" (since Tomcat 3.x and 4.0 do not have any > specific > | > | concept of a group, this is effectively what they implement). > | > | > | > | * "Group == set of roles inherited by all members of the group" > | > (supported > | > | explicitly by Tomcat 4.1). > | > | > | > | The details of how role is mapped to real-world things is up to > the > | > | container. > | > | > | > > | > How is group implemented then in 4.1 if we want to take advantage of > | > this feature? I'm looking at the HttpServletRequest API which > involves > | > getting a requested Principal, but only Role is exposed via Strings. > | > > | > | If you look at the admin tool, you'll see that you can create users, > | groups, and roles. Groups can have roles assigned to them (just like > | users can), as well as users who are members. And, of course, users > can > | be members of more than one group. > | > | When an isUserInRole() check is performed, Tomcat performs a union of > all > | the roles assigned to the user individually, and all the roles > assigned to > | groups that this user is a member of. > | > | Stored in the tomcat-users.xml file, you'll see an element for each > | <Role>, an element for each <User>, and an element for each <Group>. > The > | best wasy to see what's possible is to add some of these through the > admin > | tool, and then go examine $CATALINA_HOME/conf/tomcat-users.xml > afterwards. > | > | > Is the presumption that we cast to our own Principal (implements > User) > | > and do verification based on the now exposed groups? Granted I > would > | > start with my own UserRealm extending RealmBase with a UserDatabase > of > | > my own. > | > > | > | As I said in an earlier email, groups are ***not*** exposed to a > webapp > | through the servlet apis. The only difference is that you can assign > | roles once to a group instead of having to assign all of them > individually > | to each member, in the user database. > | > | There is no change to how security constraints are defined, or what > | isUserInRole returns - that all still happens in terms of roles. > > So, groups are implemented within the context of Tomcat's > admin/management, Yes. > not as a feature in a new Servlet API, That's true. > or Catalina's > general API. > That's true also. > If I were to implement Realm and return a ProxyPrincipal that would be > tied back to my DB, I could theoretically write my own Role schema with > my own group implementation; as long as I could provide accurate > authorization through Realm.hasRole(Principal,String). Other than that, > Tomcat won't have any issues? > Absolutely fine. Be sure to put the Realm implementation class in common/classes or common/lib so that both Tomcat and your webapp can see it. Tomcat uses Realm.authenticate() and Realm.hasRole() according to the contracts described in the Javadocs -- whatever your Realm implementation does to satisfy those calls is up to you. > I guess my main concern is writing an implementation that fits the needs > of my project without extending RealmBase or GenericPrincipal and > sticking to the java.security.Principal and org.apache.calalina.Realm > interfaces. Because of the amount of permissions that must be checked, > it's not ideal to load all roles upon authentication. > Loading all the roles into GenericPrincipal is just the way that the existing Realm implementations do it. Nothing stops you from using a Principal implementation that doesn't contain the roles, and make your Realm.hasRole() implementation do database lookups for the particular role in question. Note that your Realm implementation acts as a Factory for the Principal -- you can override RealmBase.authenticate() to return whatever kind of Principal you want, as long as you override hasRole() also. For example, it would be straightforward to create a Realm implementation that implemented every call to hasRole() as a database lookup -- although this will be slower than the current approach, it won't have the memory overhead of storing all the roles (or the computational overhead of looking all of them up). > Much Appreciated, > Jake Hookom > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
