Hi Robert, We would like to use the impersonation via a service user in the following scenario: an event handler takes care of saving an 'incoming' page and we would to have props like 'lastModifiedBy' having the correct user (hence the impersonation).
Regarding your remark "- the impersonator must be declared in a rep:impersonators property on" We would like to avoid this, as the involved users can be created ad hoc and maintainability would be become cumbersome. Thanks, Johan 2018-01-10 13:21 GMT+01:00 Robert Munteanu <[email protected]>: > Hi Johan, > > On Fri, 2018-01-05 at 23:46 +0100, Johan Ruttens wrote: > > Hi, > > > > We have to following piece of functionality: > > > > ... > > final Session adminSession = > > adminResourceResolver.adaptTo(Session.class); > > Session userSession = adminSession.impersonate(new > > SimpleCredentials(userID, "".toCharArray())); > > ... > > > > Where the adminResourceResolver used to be retrieved > > via getAdministrativeResourceResolver, but as this method is > > deprecated, we > > wanted to use the getServiceResourceResolver method. > > The problem is that the impersonate line, now throws an > > exception: "javax.jcr.LoginException: Impersonation not allowed". > > The documentation states that it is possible to add > > USER_IMPERSONATION to > > the authenticationInfo map parameter of the method. But also "The > > property > > is obeyed but requires that the actual user has permission to > > impersonate > > as the requested user. If such permission is missing, a > > LoginException is > > thrown." > > > > So my question to you guys is: do we need to add USER_IMPERSONATION > > to the > > authinfo map and which extra -minimal- permissions does the user need > > to > > able to make the impersonation work? > > > > I am not familiar with that area of the Oak code, but what I could > gather is that either: > > - the impersonator is an admin user > - the impersonator must be declared in a rep:impersonators property on > the user node ( see [1] for details ) > > From an API call point of view this should be fine. > > But OTOH I am not sure that you should be impersonating from a service > user. Sure, technically this works, but a service user should be able > to do all the required work by itself. Can you share a bit more info > about why you need impersonation to work via a service user? > > Thanks, > > Robert > > [1]: https://jackrabbit.apache.org/oak/docs/security/user/default.html# > Representation_in_the_Repository >
