Overview#About JSPWiki WIKI-Roles and WIKI-Groups. The two are fundamentally different in terms of how JSPWiki deals with them. Let me explain.
First, WIKI-Roles are assigned by the system -- either JSPWiki (internally) or externally by the web container.WIKI-Roles are related to the user's current authentication state, and are determined by JSPWiki as part of the authentication system. WIKI-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.
Differences #From the standpoint of how WIKI-Roles and WIKI-Groups are implemented, there are some key differences to be aware of.
Because WIKI-Groups are managed by JSPWiki, we have complete control of querying the database, adding and deleting WIKI-Groups , and testing for membership. That means that users who are added to WIKI-Groups receive the privileges immediately.
WIKI-Roles (container-managed ones, anyway) are treated differently by necessity. The set of WIKI-Roles that JSPWiki "knows" about is determined only when JSPWiki 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 only when they log in. This is done 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).WIKI-Roles and WIKI-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 org.apache.wiki.auth.authorize.Role. For groups, you use Principal org.apache.wiki.auth.authorize.Group.
If you grant privileges in WIKI-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 Authorization in the following order:JSPWiki will ignore it because it conflicts with a built-in role by that name. This is done to prevent Role spoofing.
Summary #Boiling this all down, here's what it means:
- WIKI-Roles (e.g., supplied by JNDIRealm) are NOT WIKI-Groups
- If you add new roles to your WIKI-Roles, they will not be recognized until you
- a) a modify web.xml to declare the WIKI-Role **AND**
- b) restart JSPWiki
- If you change an existing role managed by your WIKI-Roles, users won't see their privileges change until the next time they log in
- WIKI-Group changes have neither of these restrictions, and take effect immediately
Considerations#We 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 WIKI-Roles), rather than in WIKI-Groups?
If they don't really require an admin to create them, consider changing some of the roles into WIKI-Groups instead (and let the users manage them).
If you want to let users create the WIKI-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 WIKI-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 WIKI-Groups.