| -----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, not as a feature in a new Servlet API, or Catalina's
general API.
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?
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.
Much Appreciated,
Jake Hookom
|
| > Best Regards,
| > Jake Hookom
| >
|
| Craig
|
|
| --
| To unsubscribe, e-mail: <mailto:tomcat-user-
| [EMAIL PROTECTED]>
| For additional commands, e-mail: <mailto:tomcat-user-
| [EMAIL PROTECTED]>
|
| ---
| Incoming mail is certified Virus Free.
| Checked by AVG anti-virus system (http://www.grisoft.com).
| Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
|
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
