You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Mike Moulton <mi...@meltmedia.com> on 2010/09/10 00:47:04 UTC
Authentication/Authorization and jackrabbit.usermanager functionality
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
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
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" <mi...@meltmedia.com> 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
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Eric Norman <er...@gmail.com>.
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" <mi...@meltmedia.com> 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
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
On 13 Sep 2010, at 16:33, Felix Meschberger wrote:
> Hi,
>
> Am 12.09.2010 23:34, schrieb Ian Boston:
>>
>> On 12 Sep 2010, at 00:25, Felix Meschberger wrote:
>>
>>> 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.
>>
>>
>> +1,
>> I think we have modified out CreateUser servlet to do this, and added a hook to allow control over self registration, we use that hook to look for things like reCaptcha tokens. Is that something that should be in Sling ?
>
> Sounds like a good idea -- and, yes, very open to accept such a
> contribution ;-)
Here is a patch [1] that brings across the optimisations that we have done to the CreateUser servlet, removing duplicate user lookups (especially where the users doesn't exist, which added quite a bit to the operation), and caching of the administrative ID.
It also adds a RequestTrustValidator and interface that answers the question "what level of trust can we associated with this request", I don't think that the location of the interfaces is correct. We have put the interface next to the TokenStore bundle, but the inter bundle binding might not be appropriate.
We have an reCaptcha implementation of this interface.
Finally it adds OSGi events to user creation so other things can hook in. At the moment its an async event, but perhaps it should be sync.
WDYT? Too much, not enough ?
I havent looked through what we have done in groups at the moment.
Ian
http://codereview.appspot.com/2226042
>
> BTW: I have created a hook for self-registration in the launchpad
> content -- the signup.html page currently just displaying the usual
> "not-implemented-yet" banner. We might want to integrate that with the
> self-registration CreateUser servlet.
>
> Regards
> Felix
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am 12.09.2010 23:34, schrieb Ian Boston:
>
> On 12 Sep 2010, at 00:25, Felix Meschberger wrote:
>
>> 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.
>
>
> +1,
> I think we have modified out CreateUser servlet to do this, and added a hook to allow control over self registration, we use that hook to look for things like reCaptcha tokens. Is that something that should be in Sling ?
Sounds like a good idea -- and, yes, very open to accept such a
contribution ;-)
BTW: I have created a hook for self-registration in the launchpad
content -- the signup.html page currently just displaying the usual
"not-implemented-yet" banner. We might want to integrate that with the
self-registration CreateUser servlet.
Regards
Felix
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
On 12 Sep 2010, at 00:25, Felix Meschberger wrote:
> 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.
+1,
I think we have modified out CreateUser servlet to do this, and added a hook to allow control over self registration, we use that hook to look for things like reCaptcha tokens. Is that something that should be in Sling ?
Ian
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Justin Edelson <ju...@gmail.com>.
In that case, I guess the question is... why does the default Sling
configuration allow for anonymous users to view the user list?
Time to debug!
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
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
On 16 Sep 2010, at 06:42, Justin Edelson wrote:
> On 9/15/10 4:36 PM, Ian Boston wrote:
>>
>> On 15 Sep 2010, at 05:01, Justin Edelson wrote:
>>
>>> 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,
>> Thanks for the tip.
>> I havent looked into it, but I know I should, Sakai would like to feel its contributing back.
>> At the moment we are pushing for a release on 1 Oct, and have feature frozen, so I am probably going to have to wait until after that release.
>> Ian
>>
>>
>>
> I poked around the code a bit. I think you'd probably want to
> restructure the code to move the security API into a separate bundle as
> well as repackage everything. I'll be happy to try to help with this
> after your release (good luck with that!)
Ok, and thanks (x2)
>
> From the Sling side, I think we should be trying to ensure that these
> types of extensions are possible and easy to do without rebundling.
> Sakai is a good test bed for this capability.
From an entirely selfish point of view this would be great, keeping the duplicated code in sync is a pain and feels wrong.
At the moment the only 2 areas we extend are the server bundle and the usermanager bundle.
Most of the usermanager bundle is about performing actions post user or group creation, what I should spend some time doing is having a look at this and seeing if it cant be hooked in via sync events, so that we can revert to the Sling bundles.
Ian
>
> Justin
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
On 16 Sep 2010, at 06:42, Justin Edelson wrote:
> On 9/15/10 4:36 PM, Ian Boston wrote:
>>
>> On 15 Sep 2010, at 05:01, Justin Edelson wrote:
>>
>>> 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,
>> Thanks for the tip.
>> I havent looked into it, but I know I should, Sakai would like to feel its contributing back.
>> At the moment we are pushing for a release on 1 Oct, and have feature frozen, so I am probably going to have to wait until after that release.
>> Ian
>>
>>
>>
> I poked around the code a bit. I think you'd probably want to
> restructure the code to move the security API into a separate bundle as
> well as repackage everything. I'll be happy to try to help with this
> after your release (good luck with that!)
Had a quick look at this and there may be some issues.
IIUC in the OSGi R4 spec 3.14.2
"A host bundle’s class path is searched before a fragment’s class path"
And we need to override the Activator as well as some other classes like patching some of the core index classes. BundleActivator cant exist in a fragment (afaict)
The other problem might be the RuleAclModifier class needs to bind to protected packages internal to Jackrabbit and so have to be in the same classloader, so have to be in a modified server bundle or possibly in a fragment subject to the impl of the bundle protection.
Still looking at it.
Ian
>
> From the Sling side, I think we should be trying to ensure that these
> types of extensions are possible and easy to do without rebundling.
> Sakai is a good test bed for this capability.
>
> Justin
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Justin Edelson <ju...@gmail.com>.
On 9/15/10 4:36 PM, Ian Boston wrote:
>
> On 15 Sep 2010, at 05:01, Justin Edelson wrote:
>
>> 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,
> Thanks for the tip.
> I havent looked into it, but I know I should, Sakai would like to feel its contributing back.
> At the moment we are pushing for a release on 1 Oct, and have feature frozen, so I am probably going to have to wait until after that release.
> Ian
>
>
>
I poked around the code a bit. I think you'd probably want to
restructure the code to move the security API into a separate bundle as
well as repackage everything. I'll be happy to try to help with this
after your release (good luck with that!)
>From the Sling side, I think we should be trying to ensure that these
types of extensions are possible and easy to do without rebundling.
Sakai is a good test bed for this capability.
Justin
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
On 15 Sep 2010, at 05:01, Justin Edelson wrote:
> 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,
Thanks for the tip.
I havent looked into it, but I know I should, Sakai would like to feel its contributing back.
At the moment we are pushing for a release on 1 Oct, and have feature frozen, so I am probably going to have to wait until after that release.
Ian
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Justin Edelson <ju...@gmail.com>.
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 -Fprivilege@jcr:all=denied
>> http://admin:admin@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
>>
>
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
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 -Fprivilege@jcr:all=denied
> http://admin:admin@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
>
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Justin Edelson <ju...@gmail.com>.
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 -Fprivilege@jcr:all=denied
http://admin:admin@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
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Felix Meschberger <fm...@gmail.com>.
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
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Justin Edelson <ju...@gmail.com>.
On 9/10/10 3:41 PM, Ian Boston wrote:
>
> On 11 Sep 2010, at 04:28, Mike Moulton wrote:
>
>>> I can't speak to whether this was by intent or not, but I would
>>> definitely recommend preventing anonymous access to /system. Beyond
>>> that, it gets very application-specific quickly.
>
> That might be a bit too much as there are things under /system that anon users need access to.
> login end points and anything not real content.
>
> We have been using /system for those sorts of things, and where there is any connection to content urls starting /_*
>
> The usermanager urls certainly do need to be restricted, especially the list and locate functions admin only I suspect.
>
> Ian
Yeah. I misspoke. I meant /system/userManager, not just /system.
Justin
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Ian Boston <ie...@tfd.co.uk>.
On 11 Sep 2010, at 04:28, Mike Moulton wrote:
>> I can't speak to whether this was by intent or not, but I would
>> definitely recommend preventing anonymous access to /system. Beyond
>> that, it gets very application-specific quickly.
That might be a bit too much as there are things under /system that anon users need access to.
login end points and anything not real content.
We have been using /system for those sorts of things, and where there is any connection to content urls starting /_*
The usermanager urls certainly do need to be restricted, especially the list and locate functions admin only I suspect.
Ian
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Justin Edelson <ju...@gmail.com>.
IMHO It would be "Slingy" if this was done inside the ResourceProvider.
Perhaps there needs to be a generic path-based ACL service which non-JCR
ResourceProviders can tap into.
Justin
On 9/10/10 3:07 PM, Eric Norman wrote:
> Perhaps we could just create a filter that does simple 'role' based access
> checking.
>
> The filter could have a configuable map between resource path patterns and
> the groupId the user must be a member of to read the resource.
>
> The launchpad could pre-create some well known goups and provide the default
> mappings for the filter.
>
> WDYT?
>
> Regards, eric
>
> On Sep 10, 2010 11:29 AM, "Mike Moulton" <mi...@meltmedia.com> wrote:
>
> I can create patches then to prevent anon access. What do you think about
> tying the authorization to existing JCR ACL's like jcr:readAccessControl or
> jcr:modifyAccessControl? If there is interest, I can include this in my
> patches.
>
> -- Mike
>
>
>
> On Sep 9, 2010, at 5:07 PM, Justin Edelson wrote:
>
>> I can't speak to whether this was by intent o...
>
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Eric Norman <er...@gmail.com>.
Perhaps we could just create a filter that does simple 'role' based access
checking.
The filter could have a configuable map between resource path patterns and
the groupId the user must be a member of to read the resource.
The launchpad could pre-create some well known goups and provide the default
mappings for the filter.
WDYT?
Regards, eric
On Sep 10, 2010 11:29 AM, "Mike Moulton" <mi...@meltmedia.com> wrote:
I can create patches then to prevent anon access. What do you think about
tying the authorization to existing JCR ACL's like jcr:readAccessControl or
jcr:modifyAccessControl? If there is interest, I can include this in my
patches.
-- Mike
On Sep 9, 2010, at 5:07 PM, Justin Edelson wrote:
> I can't speak to whether this was by intent o...
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Mike Moulton <mi...@meltmedia.com>.
I can create patches then to prevent anon access. What do you think about tying the authorization to existing JCR ACL's like jcr:readAccessControl or jcr:modifyAccessControl? If there is interest, I can include this in my patches.
-- Mike
On Sep 9, 2010, at 5:07 PM, Justin Edelson wrote:
> I can't speak to whether this was by intent or not, but I would
> definitely recommend preventing anonymous access to /system. Beyond
> that, it gets very application-specific quickly.
>
> Justin
>
> On 9/9/10 6:47 PM, Mike Moulton 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
>
Re: Authentication/Authorization and jackrabbit.usermanager functionality
Posted by Justin Edelson <ju...@gmail.com>.
I can't speak to whether this was by intent or not, but I would
definitely recommend preventing anonymous access to /system. Beyond
that, it gets very application-specific quickly.
Justin
On 9/9/10 6:47 PM, Mike Moulton 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