FYI - Created JCR-2748 and submitted a patch to provide a simple way to disable anonymous access to the security workspace.
Ian - have you looked at turning the Sakai server bundle into a fragment attached to the Sling JCR Jackrabbit Server bundle? I do that with a custom FileSystem and DataSource implementation and it seems to work OK. Having this as a fragment would make it easier for other projects to consume, although I understand if that isn't really the point of Sakai. Justin On 9/13/10 7:09 PM, Ian Boston wrote: > IIRC the security workspace is not set up with access controllable nodes, so > you cant use a policy on a node. > > We did [1] for the securty workspace. > > 1 > http://github.com/sakaiproject/nakamura/blob/master/bundles/server/src/main/java/org/apache/jackrabbit/core/security/user/DelegatedUserAccessControlProvider.java > > > On 14 Sep 2010, at 05:34, Justin Edelson wrote: > >> Oh... I get it. There's no ACL on the user and group nodes in the >> security workspace. >> >> But trying to apply an ACL to / or /rep:security returns an exception >> >> $ curl-FprincipalId=anonymous -fprivil...@jcr:all=denied >> http://admin:ad...@localhost:8888/rep:security.modifyAce.html?sling.workspace=security >> >> <html> >> <head> >> <title>Error while processing security:/rep:security</title> >> </head> >> <body> >> <h1>Error while processing security:/rep:security</h1> >> <table> >> <tbody> >> <tr> >> <td>Status</td> >> <td><div id="Status">500</div></td> >> </tr> >> <tr> >> <td>Message</td> >> <td><div id="Message">javax.jcr.RepositoryException: >> Failed to create ace.</div></td> >> </tr> >> <tr> >> <td>Location</td> >> <td><a href="/_rep_security" >> id="Location">/_rep_security</a></td> >> </tr> >> <tr> >> <td>Parent Location</td> >> <td><a href="/" id="ParentLocation">/</a></td> >> </tr> >> <tr> >> <td>Path</td> >> <td><div id="Path">security:/rep:security</div></td> >> </tr> >> <tr> >> <td>Referer</td> >> <td><a href="" id="Referer"></a></td> >> </tr> >> <tr> >> <td>ChangeLog</td> >> <td><div id="ChangeLog"><pre></pre></div></td> >> </tr> >> </tbody> >> </table> >> <p><a href="">Go Back</a></p> >> <p><a href="/_rep_security">Modified Resource</a></p> >> <p><a href="/">Parent of Modified Resource</a></p> >> </body> >> </html> >> >> On 9/11/10 10:25 AM, Felix Meschberger wrote: >>> Hi, >>> >>> Unless I am completely mistaken, the usermanager uses the request's >>> session to get at the Jackrabbit UserManager to do any tasks, which is >>> the absolutely correct thing IMHO. >>> >>> We should definitely leave this kind of access control to Jackrabbit >>> (resp. the configured functionality of Jackrabbit) and not impose our >>> own idea ontop of it. >>> >>> There is one situation where an admin session is always retrieved: The >>> CreeateUser servlet. This is probably a bug and should only use an admin >>> session for self-registration. >>> >>> Regards >>> Felix >>> >>> Am 10.09.2010 00:47, schrieb Mike Moulton: >>>> 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 >> >
