!!! Overview
About [JSPWiki] [WIKI-Roles] and [WIKI-Groups] are two fundamentally different in terms of how [JSPWiki] deals with them.

First, [WIKI-Roles] are assigned by the system -- either [JSPWiki] (internally) or externally by the web container. 

!!! [WIKI-Roles] 
Roles can be either "built-in" or container-managed. By "built-in" roles, we mean roles ALL, AUTHENTICATED, ANONYMOUS, and ASSERTED. [WIKI-Roles] are related to the user's current authentication state, and are determined by JSPWiki as part of the authentication system. 

!!! [WIKI-Groups] 
[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-ACLs]
From the policy and access control list (ACL) perspective, you can use both [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:
* ["built-in" roles|WIKI-Roles#WIKI-Roles-BuiltInWIKIRoles]
* [container-managed roles|WIKI-Roles#AdditionalContainerManagedWIKIRoles]
* [WIKI-Groups] 
* [WIKI-Profiles]
This is also the order in which naming conflicts are resolved. If your container emits a role called "Anonymous," [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 [JNDI Realm|Tomcat And LDAP]) 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]. 

Regards, 
Andrew 


!! More Information 
There might be more information for this subject on one of the following: 
[{ReferringPagesPlugin before='*' after='\n' }]