Andrew, Good explanation. Hope you post in to JSPWiki documentation
Terry On Mon, 2008-08-18 at 00:29 -0400, Andrew Jaquith wrote: > 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
