jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@me.com>
Subject Re: Adding memebers to groupdatabase.xml problem
Date Mon, 18 Aug 2008 04:29:32 GMT
Hi Jim --

The issue you've described is really about container ROLES, not  
JSPWiki groups. The two are fundamentally different in terms of how  
JSPWiki deals with them. Let me explain.

First, ROLES are assigned by the system -- either JSPWiki or  
externally by the web application server (aka web container). Roles  
can be either "built-in" or container-managed. By "built-in" roles, we  
related to the user's current authentication state, and are assigned  
by JSPWiki as part of the authentication system.

Container-managed roles are those that are maintained outside of  
JSPWiki by the web container. The JNDIRealm you described, for  
example, is a container-managed realm that supplies roles that JSPWiki  
can use. For JSPWiki to use them, they must be declared in the JSPWiki  
webapp's web.xml file (typically using role-ref elements). At startup,  
JSPWiki parses web.xml and caches the set of roles that are declared  
there. When a user logs in, we check to see whether the user is a  
member of any of those roles. If so, the user is regarded as  
"belonging" to that role. It is important to remember, again, that  
what we are talking about here is ROLE membership, not GROUP membership.

Second, GROUPS are discretionary sets of users that have decided to  
associate themselves into a group. Functionally, they are just like  
roles, but with a key difference: groups are managed by JSPWiki and  
not by the container. Technically, groups are stored using a  
GroupDatabase implementation; by default, this is the XML-based  
XMLGroupDatabase. Groups were deliberately meant to be managed outside  
of the web container, so that users can create discretionary "roles"  
without getting system admins involved. This is an intentional  
feature, and a very powerful one.

 From the standpoint of how roles and groups are implemented, there  
are some key differences to be aware of. Because groups are managed by  
JSPWiki, we have complete control of querying the database, adding and  
deleting groups, and testing for membership. That means that users who  
are added to groups receive these privileges immediately.

Roles (container-managed ones, anyway) are treated differently by  
necessity. The set of roles that JSPWiki "knows" about is determined  
only once -- when the webapp starts. Specifically, this happens when  
WebContainerAuthorizer's initialize() method parses web.xml.

Next, users are tested for membership in that set of "known" container  
roles (by calling HttpServletResponse.isInRole()) also only once --  
when they log in. We do this for performance reasons: it would be a  
huge drain on performance to query the set of known container roles  
every time we needed to do an authorization check (which could be done  
several dozen times PER page).

 From the policy and access control list (ACL) perspective, you can  
use both roles and groups interchangeably, although the policy file  
syntax differs slightly. To grant privileges via the jspwiki.policy  
file to a role (either container-managed, or a built-in one), you use  
the Principal com.ecyrd.jspwiki.auth.authorize.Role. For groups, you  
use Principal com.ecyrd.jspwiki.auth.GroupPrincipal.

If you grant privileges in ACLs, you don't need to specify whether  
it's a role or group; you can just specify names like Foo, Bar, All,  
or Authenticated. JSPWiki prioritizes "built-in" roles All/ 
Authenticated/Asserted/Anonymous first, then container-managed roles,  
then groups, then regular user names. This is the order in which  
naming conflicts are resolved. So, if your container emits a role  
called "Anonymous," JSPWiki will ignore it because it conflicts with a  
built-in role by that name. We do this to prevent spoofing.

Boiling this all down, here's what it means:
1. Container-managed roles (e.g., supplied by JNDIRealm) are NOT groups
2. If you add new roles to your container, they will not be recognized  
until you a) a modify web.xml to declare the role **AND** b) restart  
3. If you change an existing role managed by your container, users  
won't see their privileges change until the next time they log in
4. Group changes have neither of these restrictions, and take effect  

It sounds like the problem you have is related to points 2 and 3. I'd  
suggest that you take a careful look at how you are provisioning roles  
with your web container. Do you need to keep all of them in your web  
container (as roles), rather than in JSPWiki (as groups)? If they  
don't really require an admin to create them, consider changing some  
of the roles into groups instead (and let the users manage them).

If you want to let users create the groups themselves -- AND need to  
share them with other apps -- you might instead want to implement your  
own GroupDatabase to interface with JNDI. Bear in mind, however, that  
GroupDatabases are expected to have read-write access to the back end  
(LDAP in your example). If you need to restrict who gets to create  
groups, of course, you can do this by modifying your security policy.  
So even though your (hypothetical) JNDIGroupDatabase would have full  
access to the branch of LDAP that stores your multi-app groups, you  
could still make sure that just the "Admin" group (or "Admin"  
container role) would be the only ones adding or editing groups.



On Aug 15, 2008, at 7:42 AM, Jim Willeke wrote:

> We are using LDAP and have an attribute on the Users within LDAP to
> implement the groups.
> In out tomcat server.xml file:
> 			<Realm className="org.apache.catalina.realm.JNDIRealm" debug="10"
> 				connectionURL="ldap://192.168.x.x:389"
> 				alternateURL="ldap://192.168.xx.xx:389"
> 				userBase="ou=people,dc=willeke,dc=com"
> 				userSearch="(cn={0})"
> 				userSubtree="true"
> 				userRoleName="dictcrole"
> 				connectionName="cn=admin,ou=administration,dc=willeke,dc=com"
> 				connectionPassword="secret"
> Then a typical user in LDAP:
> dictcRole=manager
> dictcRole=Authenticated
> dictcRole=linux
> Which represent the groups used within the Wiki.
> (Ok we really use these same attributes for other apps too)
> When a value is changed in LDAP, they are effective on the next login.
> -jim
> On Thu, Aug 14, 2008 at 5:51 PM, Janne Jalkanen
> <Janne.Jalkanen@ecyrd.com> wrote:
>> Hi!
>> JSPWiki assumes it owns the backend.  So changing the backend  
>> outside of
>> JSPWiki system is simply not supported.  The fact that it happens  
>> to work in
>> some cases is completely accidental.
>> The only way to change this behaviour is to change the  
>> XMLGroupDatabase, or
>> write your own GroupDatabase implementation.
>> /Janne
>> On 15 Aug 2008, at 00:26, anitasingh wrote:
>>> Hi,
>>> We have installed jspwiki 2.4.102 on Websphere5.1 and Tomcat. It  
>>> works
>>> great
>>> except one problem.
>>> We add users and assign them to different groups through another  
>>> existing
>>> system. The existing system
>>> updates the userdatabase.xml to add the user to wiki and also adds  
>>> the
>>> user
>>> to chosen group in groupdatabase.xml.
>>> When we add a new user to userdatabase.xml the user has immidiate  
>>> login to
>>> jspwiki but when we assign the user to a group,  his group  
>>> privileges
>>> doesn't work until we restart japwiki.
>>> If we assign the user to a  group through jspwiki admin, we do not  
>>> need to
>>> restart wiki for the user to get his privileges.
>>> Is this by design or I am missing something in configuration.
>>> If its by design, what I can do to not have to restart jspwiki  
>>> everytime
>>> we
>>> add a member to an existing group through another backend system.
>>> Appreciate your help.
>>> TIA
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Adding-memebers-to-groupdatabase.xml-problem-tp18990033p18990033.html
>>> Sent from the JspWiki - User mailing list archive at Nabble.com.
> -- 
> -jim
> Jim Willeke

View raw message