Yes, thats correct, we found it a little too limiting for out needs. We did a role based ACL for the users and groups that added principals as viewers or managers of groups, implemented as an AccessControlManager on the security workspace iirc.
If there are any viewers listed, only those viewers can see a group. Only admin and a principals in the managers properties can modify a group (including the viewers and managers lists). And, only admin, UserAdmin, GroupAdmin or a request bearing a suitable token (eg reCaptcha) can create users or groups, although that last bit was in the servlets. We havent made the "manage" list of principals any more specific, since manage means can change the ACLs on the user or group.... ohh and by principal I mean, the requesting user has the principal which might be a user or group principal. If this of interest to Sling, I can slice out the code into something for code review, but It does hook into jackrabbit internals. Ian On 11 Sep 2010, at 05:11, Eric Norman wrote: > I believe the jackrabbit user manager already requires that the user must be > a member of the "UserAdmin" group to create or modify users. And the user > must be a member of the "GroupAdmin" group to create or modify groups. > > On Sep 9, 2010 3:47 PM, "Mike Moulton" <[email protected]> wrote: > > I recently had the need to get a list of users from an AJAX style client and > found the jackrabbit usermanager exposes this functionality at > system/userManager/user. As a part of this discovery, I noticed the listing > of JCR users is not restricted in any way. If the usermanager bundle is > installed, the following endpoint is open to the public: > http://localhost:8080/system/userManager/user.tidy.1.json, providing a > complete user list to anyone digging around. Any usermanager command that > allows modifications to the JCR first checks if the user is an admin, but it > seems all the read-only commands skip this check. > > Is this by intention, or was this simply missed? > > In addition, what are the thoughts on adding some sort of authorization > component beyond just the isAdmin check? Maybe inspecting the > jcr:readAccessControl / jcr:modifyAccessControl for the root node? > > -- Mike
