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
