Andrew, thanks for this excellent explanation, it is very clear and usable.
regards, Harry 2008/8/18 Andrew Jaquith <[EMAIL PROTECTED]> > 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 mean roles ALL, > AUTHENTICATED, ANONYMOUS, and ASSERTED. These are 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 JSPWiki > 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 > immediately > > 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. > > Regards, > > Andrew > > 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 >> <[EMAIL PROTECTED]> 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 >> > > -- met vriendelijke groet, Harry Metske Telnr. +31-548-512395 Mobile +31-6-51898081
