incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harry Metske" <harry.met...@gmail.com>
Subject Re: Adding memebers to groupdatabase.xml problem
Date Mon, 18 Aug 2008 04:58:53 GMT
Andrew,

thanks for this excellent explanation, it is very clear and usable.

regards,
Harry

2008/8/18 Andrew Jaquith <andrew.jaquith@me.com>

> 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
>>
>
>


-- 
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081

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