On Wed, 2018-01-10 at 14:12 +0100, Johan Ruttens wrote: > 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).
(Sorry for the late reply, this slipped) If the lastModifiedBy property is not protected, you can set it manually to the right value. Robert > > 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.h > > tml# > > Representation_in_the_Repository > >
