sling-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate Angell <>
Subject Re: additional sudoers?
Date Mon, 27 Feb 2012 18:27:15 GMT
Thanks for helping think this through Ian...I certainly wouldn't
presume to tell you how the system you wrote behaves ;)

My experiments show that when one impersonates a user, and then
creates a Sakai OAE doc while impersonating, the following values
associated with that document are aligned with the user being
impersonated (in this example the admin user was impersonating the
xolotl user):

    "_created": 1330366895100,
    "_createdBy": "admin",
    "_id": "4YnjwGFvEeGYOZaTCgABEA+",
    "_lastModified": 1330366896495,
    "_lastModifiedBy": "xolotl",
    "_mimeType": "x-sakai/document",
    "_path": "k8EOEcyUaa",
    "sakai:allowcomments": "true",
    "sakai:copyright": "creativecommons",
    "sakai:description": "TBD",
    "sakai:permissions": "public",
    "sakai:pool-content-created-for": "xolotl",
    "sakai:pooled-content-editor": [],
    "sakai:pooled-content-file-name": "Sudo Item",
    "sakai:pooled-content-manager": [
    "sakai:pooled-content-viewer": [
    "sakai:showcomments": "true",
    "sling:resourceType": "sakai/pooled-content",

= nate

On Sun, Feb 26, 2012 at 6:07 PM, Ian Boston <> wrote:
> Hmm, Interesting because the underlying content system used by OAE
> does not support impersonation [1] (I should know, I wrote it, but
> then I do forget things from time to time :)).
> I guess that when the custom UserManager is created by Jackrabbit its
> already impersonating the user, which doesn't exactly conform to the
> "impersonate but dont become" standard used in Sling.
> Just check that when you update a content item in oae, not Jackrabbit
> with a POST it gets the lastModifiedBy field set to the user you are
> impersonating. If it does, you are impersonating. There might be some
> other evidence of impersonation.
> <oaespecific>
> Note, this is now Sakai OAE specific and not the way to do it in Sling
> To allow user X to impersonate user Y, I think user X needs to have
> one of the principals that user Y has listed in its "impersonators"
> property. That principal can be a group X is a member of or the user X
> principal. You can set using the user manager as admin or the user
> </oaespecific>
> The UpdateUserServlet in Sling should allow you to set that property
> if you are allowed to write to the User in question.
> In Jackrabbit the property is "rep:impersonators", which may be
> protected to admin write only.(?)
> There is a grantImpersonation and denyImpersonation method in the
> Impersonator API, however I am not sure how to invoke that via REST. I
> can't find any calls to that method within Sling itself.
> 1
> On 27 February 2012 11:31, Nate Angell <> wrote:
>> Thanks Ian!
>> We have already been using what I take to be standard Sling
>> impersonation in OAE, which for the admin user at least seems to work
>> OOTB now.
>> What I'm poking at is trying to give another user the same sudo
>> capabilities admin has now. Adding a user to the administrators group
>> in OAE does not seem to grant that special power ;(
>> Perhaps some digging into the areas you provided would address the
>> issue. What I've been trying to locate is how one would give another
>> user sudo powers in a standard sling context, as it appears that at
>> least the admin user already has that capability (and it magically
>> works in OAE).
>> = Nate
>> On Feb 26, 2012, at 3:57 PM, Ian Boston <> wrote:
>>> Nate,
>>> Sakai OAE uses a custom Jackrabbit UserManager implementation and a
>>> patched version of Jackrabbit, so impersonation may or may not work. I
>>> don't think anyone has tried.
>>> Also, I don't think that the non-jackrabbit content system under Sakai
>>> OAE  supports impersonation, at least, not in the same way Jackrabbit
>>> supports impersonation and since I suspect you want to impersonate
>>> operations on that content system as well as the Jackrabbit JCR
>>> repository, you may have to do some work.
>>> The LoginModule[1] responds to the request to impersonate a user by
>>> looking in the target users impersonator field to grant or not
>>> impersonation, but there appears to be no modification of the non
>>> jackrabbit session to make it impersonate.
>>> Setting, and unsetting:
>>> You can do this directly via the Jackrabbit Impersonation impl you
>>> have in Sakai OAE [2], or by setting the appropriate properties in the
>>> Sakai OAE user object.
>>> If you were using a stock Apache Sling ontop of an unmodified version
>>> of Jackrabbit I think you would need to, grant impersonation against
>>> the Jackrabbit user, and then write a authentication handler that
>>> created credentials implementing the Impersonation callback. See the
>>> standard LoginModule implementation in Sling.
>>> Sorry, that's not a great deal of help.
>>> Ian
>>> 1
>>> 2
>>> On 27 February 2012 09:13, Nate Angell <> wrote:
>>>> I'm working with Sakai OAE, a platform built on Apache Sling.
>>>> I understand how the root admin identity can sudo as another user, but
>>>> I've been trying to figure out how one might make additional users
>>>> also be able to sudo.
>>>> Can someone point me to some documentation or a hint about whether
>>>> this is possible, and if so, how?
>>>> Thanks!
>>>> --
>>>> Nate Angell
>>>> Sakai Product Manager
>>>> rSmart
>>>> = gchat
>>>> ixmati = AIM, skype
>>>> nthangell = yahoo, .mac
>>>> 209965525 = ICQ

View raw message