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": [
"xolotl"
],
"sakai:pooled-content-viewer": [
"everyone",
"anonymous"
],
"sakai:showcomments": "true",
"sling:resourceType": "sakai/pooled-content",
"structure0":
"{\"page1\":{\"_ref\":\"id7469356\",\"_order\":0,\"_title\":\"Sudo
Item\",\"main\":{\"_ref\":\"id7469356\",\"_order\":0,\"_title\":\"Sudo
Item\"}}}"
}
= nate
On Sun, Feb 26, 2012 at 6:07 PM, Ian Boston <[email protected]> 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
> https://github.com/ieb/sparsemapcontent/blob/master/src/main/java/org/sakaiproject/nakamura/lite/SessionImpl.java
>
> On 27 February 2012 11:31, Nate Angell <[email protected]> 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 <[email protected]> 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
>>> https://github.com/sakaiproject/nakamura/blob/master/bundles/server/src/main/java/org/sakaiproject/nakamura/lite/jackrabbit/SparseLoginModule.java#L118
>>> 2
>>> https://github.com/sakaiproject/nakamura/blob/master/bundles/server/src/main/java/org/sakaiproject/nakamura/lite/jackrabbit/SparseImpersonationImpl.java#L85
>>>
>>>
>>> On 27 February 2012 09:13, Nate Angell <[email protected]> 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
>>>> [email protected] = gchat
>>>> ixmati = AIM, skype
>>>> nthangell = yahoo, .mac
>>>> 209965525 = ICQ
>>>> http://www.rsmart.com
>>>> http://twitter.com/xolotl
>>>> http://xolotl.org
