incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Steichen <te...@net-frame.com>
Subject Re: Adding memebers to groupdatabase.xml problem
Date Mon, 18 Aug 2008 12:19:38 GMT
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
> > <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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message