Oops ... one correction below. On Mon, 12 Aug 2002, Craig R. McClanahan wrote:
> Date: Mon, 12 Aug 2002 20:42:48 -0700 (PDT) > From: Craig R. McClanahan <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: RE: [Q] Realms, Principals, et al... > > 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. > Sorry ... I meant the *Principal* implementation class. And that's actually only necessary if your webapp wants to subclass it to access private information. If the webapp doesn't do that, then the Principal implementation class can be in server/classes or server/lib along with the Realm implementation class. > 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 > Craig > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
