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.
> Best Regards,
> Jake Hookom
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
