You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Johan Ruttens <jo...@gmail.com> on 2018/01/05 22:46:16 UTC
Impersonation via ServiceResourceResolver
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?
Thanks for the help!
Re: Impersonation via ServiceResourceResolver
Posted by Robert Munteanu <ro...@apache.org>.
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 <ro...@apache.org>:
>
> > 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
> >
Re: Impersonation via ServiceResourceResolver
Posted by Johan Ruttens <jo...@gmail.com>.
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 <ro...@apache.org>:
> 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
>
Re: Impersonation via ServiceResourceResolver
Posted by Robert Munteanu <ro...@apache.org>.
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