Deprecation of SlingRepository.loginAdministrative()

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecation of SlingRepository.loginAdministrative()

Jörg Hoh
Hi

taking Robert's statement as starting point for a new discussion I wanted
to raise for quite some time :-)

2018-02-06 11:37 GMT+01:00 Robert Munteanu <[hidden email]>:

>
> Sometimes it's ok to use login administrative, and I guess provisioning
> system users and overall repository initialization is one of those
> scenarios.
>
>

That's an interesting statement, because I also see clearly usecases where
a full admin session is necessary. Two usecases for it:

* My code needs to open a session and work with it on behalf of users,
which are determined during runtime. That can be easily achieved with an
admin session and impersonation. To emulate this this with a system user, I
have to configure every user to allow impersonation from this service user.

* Package installation and deployment. During that time I have to write to
/apps and /libs and potentially many other and build time unknown
locations, which can only be solved reliably by granting read/write access
to the root node. Plus capabilities to create nodetypes etc. Of course this
can be emulated by a service user as well, but in the end this service user
has nearly the same permissions as admin.

Long story short: Is the loginAdministrative() method planned to be
removed? If yes, we should clearly give best practices and document how it
can be replaced even in the non-trivial cases. If it's going to stay, we
should remove the deprecation warning.


--
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation of SlingRepository.loginAdministrative()

Bertrand Delacretaz
On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <[hidden email]> wrote:
> ...Long story short: Is the loginAdministrative() method planned to be
> removed? If yes, we should clearly give best practices and document how it
> can be replaced even in the non-trivial cases. If it's going to stay, we
> should remove the deprecation warning....

I think we need to keep warnings that loginAdmin should be used as
sparingly as possible.

And probably provide some examples where it does make sense to use it.

But deprecation might not be the correct term, as you indicate.

-Bertrand
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation of SlingRepository.loginAdministrative()

Andres Bott
Maybe a solution would be
- deprecate / remove the method ( to avoid old code to run as admin)
- rename the class / method and add an info to the log

in this way we make sure that old code gets migrated to service users,
and the places where it really makes sense to use admin user, the
developer should be aware of it.

Andres


El 2018-02-06 14:09, Bertrand Delacretaz escribió:

> On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <[hidden email]>
> wrote:
>> ...Long story short: Is the loginAdministrative() method planned to be
>> removed? If yes, we should clearly give best practices and document
>> how it
>> can be replaced even in the non-trivial cases. If it's going to stay,
>> we
>> should remove the deprecation warning....
>
> I think we need to keep warnings that loginAdmin should be used as
> sparingly as possible.
>
> And probably provide some examples where it does make sense to use it.
>
> But deprecation might not be the correct term, as you indicate.
>
> -Bertrand
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation of SlingRepository.loginAdministrative()

Roy Teeuwen
Hey Andres,

We had a similar use case to do impersonation, there is another method for that now:


Greets,
Roy

On 7 Feb 2018, at 20:49, Andres Bott <[hidden email]> wrote:

Maybe a solution would be
- deprecate / remove the method ( to avoid old code to run as admin)
- rename the class / method and add an info to the log

in this way we make sure that old code gets migrated to service users, and the places where it really makes sense to use admin user, the developer should be aware of it.

Andres


El 2018-02-06 14:09, Bertrand Delacretaz escribió:
On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <[hidden email]> wrote:
...Long story short: Is the loginAdministrative() method planned to be
removed? If yes, we should clearly give best practices and document how it
can be replaced even in the non-trivial cases. If it's going to stay, we
should remove the deprecation warning....
I think we need to keep warnings that loginAdmin should be used as
sparingly as possible.
And probably provide some examples where it does make sense to use it.
But deprecation might not be the correct term, as you indicate.
-Bertrand


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation of SlingRepository.loginAdministrative()

Jörg Hoh
Hi Roy,

that's indeed good news, as it seems to solve the impersonation usecase. On
the other hand the javadoc is quite clear, that the requirements of the
impersonation process itself come from the underlying repository. I
typically use Oak and the Oak documentation at [1] says that with the
DefaultLoginModule it still requires some kind of prerequisits
("Impersonation another user will only succeed if the impersonated user is
valid (i.e. exists and is not disabled) *and* the the user associated with
the editing session is allowed to impersonate this user.").


Jörg



[1]
https://jackrabbit.apache.org/oak/docs/security/authentication/default.html#impersonation



2018-02-07 22:50 GMT+01:00 Roy Teeuwen <[hidden email]>:

> Hey Andres,
>
> We had a similar use case to do impersonation, there is another method for
> that now:
>
> https://sling.apache.org/apidocs/sling10/org/apache/
> sling/jcr/api/SlingRepository.html#impersonateFromService-
> java.lang.String-javax.jcr.Credentials-java.lang.String-
>
> Greets,
> Roy
>
>
> On 7 Feb 2018, at 20:49, Andres Bott <[hidden email]> wrote:
>
> Maybe a solution would be
> - deprecate / remove the method ( to avoid old code to run as admin)
> - rename the class / method and add an info to the log
>
> in this way we make sure that old code gets migrated to service users, and
> the places where it really makes sense to use admin user, the developer
> should be aware of it.
>
> Andres
>
>
> El 2018-02-06 14:09, Bertrand Delacretaz escribió:
>
> On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <[hidden email]> wrote:
>
> ...Long story short: Is the loginAdministrative() method planned to be
> removed? If yes, we should clearly give best practices and document how it
> can be replaced even in the non-trivial cases. If it's going to stay, we
> should remove the deprecation warning....
>
> I think we need to keep warnings that loginAdmin should be used as
> sparingly as possible.
> And probably provide some examples where it does make sense to use it.
> But deprecation might not be the correct term, as you indicate.
> -Bertrand
>
>
>


--
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation of SlingRepository.loginAdministrative()

Alexander Klimetschek-3
I had the same question previously. It is not very feasible to configure a service user as a delegate on each individual human user. Especially when these human users are constantly added or removed.

This is a question for Oak, I believe.

Cheers,
Alex

> On 07.02.2018, at 14:03, Jörg Hoh <[hidden email]> wrote:
>
> Hi Roy,
>
> that's indeed good news, as it seems to solve the impersonation usecase. On
> the other hand the javadoc is quite clear, that the requirements of the
> impersonation process itself come from the underlying repository. I
> typically use Oak and the Oak documentation at [1] says that with the
> DefaultLoginModule it still requires some kind of prerequisits
> ("Impersonation another user will only succeed if the impersonated user is
> valid (i.e. exists and is not disabled) *and* the the user associated with
> the editing session is allowed to impersonate this user.").
>
>
> Jörg
>
>
>
> [1]
> https://jackrabbit.apache.org/oak/docs/security/authentication/default.html#impersonation
>
>
>
> 2018-02-07 22:50 GMT+01:00 Roy Teeuwen <[hidden email]>:
>
>> Hey Andres,
>>
>> We had a similar use case to do impersonation, there is another method for
>> that now:
>>
>> https://sling.apache.org/apidocs/sling10/org/apache/
>> sling/jcr/api/SlingRepository.html#impersonateFromService-
>> java.lang.String-javax.jcr.Credentials-java.lang.String-
>>
>> Greets,
>> Roy
>>
>>
>> On 7 Feb 2018, at 20:49, Andres Bott <[hidden email]> wrote:
>>
>> Maybe a solution would be
>> - deprecate / remove the method ( to avoid old code to run as admin)
>> - rename the class / method and add an info to the log
>>
>> in this way we make sure that old code gets migrated to service users, and
>> the places where it really makes sense to use admin user, the developer
>> should be aware of it.
>>
>> Andres
>>
>>
>> El 2018-02-06 14:09, Bertrand Delacretaz escribió:
>>
>> On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <[hidden email]> wrote:
>>
>> ...Long story short: Is the loginAdministrative() method planned to be
>> removed? If yes, we should clearly give best practices and document how it
>> can be replaced even in the non-trivial cases. If it's going to stay, we
>> should remove the deprecation warning....
>>
>> I think we need to keep warnings that loginAdmin should be used as
>> sparingly as possible.
>> And probably provide some examples where it does make sense to use it.
>> But deprecation might not be the correct term, as you indicate.
>> -Bertrand
>>
>>
>>
>
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh

Reply | Threaded
Open this post in threaded view
|

Re: Deprecation of SlingRepository.loginAdministrative()

Roy Teeuwen
Hey Jörg, Alexander,

Maybe it's just me, but for me the method works (on an AEM 6.3) without putting any impersonators on any user, thats why I of course mentioned the method, else it wouldn't have answered the question:

def session = slingRepository.impersonateFromService("my-service", new SimpleCredentials("my-user", "".toCharArray()), (String)null);

Maybe this is a security flaw :)? The reason I use it like this is because I also found that AEM itself uses this method to modify pages in name of users in workflows / jobs...

Greets,
Roy

> On 8 Feb 2018, at 00:25, Alexander Klimetschek <[hidden email]> wrote:
>
> I had the same question previously. It is not very feasible to configure a service user as a delegate on each individual human user. Especially when these human users are constantly added or removed.
>
> This is a question for Oak, I believe.
>
> Cheers,
> Alex
>
>> On 07.02.2018, at 14:03, Jörg Hoh <[hidden email]> wrote:
>>
>> Hi Roy,
>>
>> that's indeed good news, as it seems to solve the impersonation usecase. On
>> the other hand the javadoc is quite clear, that the requirements of the
>> impersonation process itself come from the underlying repository. I
>> typically use Oak and the Oak documentation at [1] says that with the
>> DefaultLoginModule it still requires some kind of prerequisits
>> ("Impersonation another user will only succeed if the impersonated user is
>> valid (i.e. exists and is not disabled) *and* the the user associated with
>> the editing session is allowed to impersonate this user.").
>>
>>
>> Jörg
>>
>>
>>
>> [1]
>> https://jackrabbit.apache.org/oak/docs/security/authentication/default.html#impersonation
>>
>>
>>
>> 2018-02-07 22:50 GMT+01:00 Roy Teeuwen <[hidden email]>:
>>
>>> Hey Andres,
>>>
>>> We had a similar use case to do impersonation, there is another method for
>>> that now:
>>>
>>> https://sling.apache.org/apidocs/sling10/org/apache/
>>> sling/jcr/api/SlingRepository.html#impersonateFromService-
>>> java.lang.String-javax.jcr.Credentials-java.lang.String-
>>>
>>> Greets,
>>> Roy
>>>
>>>
>>> On 7 Feb 2018, at 20:49, Andres Bott <[hidden email]> wrote:
>>>
>>> Maybe a solution would be
>>> - deprecate / remove the method ( to avoid old code to run as admin)
>>> - rename the class / method and add an info to the log
>>>
>>> in this way we make sure that old code gets migrated to service users, and
>>> the places where it really makes sense to use admin user, the developer
>>> should be aware of it.
>>>
>>> Andres
>>>
>>>
>>> El 2018-02-06 14:09, Bertrand Delacretaz escribió:
>>>
>>> On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <[hidden email]> wrote:
>>>
>>> ...Long story short: Is the loginAdministrative() method planned to be
>>> removed? If yes, we should clearly give best practices and document how it
>>> can be replaced even in the non-trivial cases. If it's going to stay, we
>>> should remove the deprecation warning....
>>>
>>> I think we need to keep warnings that loginAdmin should be used as
>>> sparingly as possible.
>>> And probably provide some examples where it does make sense to use it.
>>> But deprecation might not be the correct term, as you indicate.
>>> -Bertrand
>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Jörg Hoh,
>>
>> http://cqdump.wordpress.com
>> Twitter: @joerghoh
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation of SlingRepository.loginAdministrative()

Alexander Klimetschek-3
I believe at one point this impersonateFromService was implemented using an admin session, i.e. essentially ignoring the "my-service" service user name argument. And maybe that implementation is still used in AEM 6.3. However, the current state of Sling and Oak would actually use a service user, and your code might fail to work.

But when I searched, I couldn't find the source code showing that history.

Does anyone know?

Cheers,
Alex

> On 08.02.2018, at 01:07, Roy Teeuwen <[hidden email]> wrote:
>
> Hey Jörg, Alexander,
>
> Maybe it's just me, but for me the method works (on an AEM 6.3) without putting any impersonators on any user, thats why I of course mentioned the method, else it wouldn't have answered the question:
>
> def session = slingRepository.impersonateFromService("my-service", new SimpleCredentials("my-user", "".toCharArray()), (String)null);
>
> Maybe this is a security flaw :)? The reason I use it like this is because I also found that AEM itself uses this method to modify pages in name of users in workflows / jobs...
>
> Greets,
> Roy
>
>> On 8 Feb 2018, at 00:25, Alexander Klimetschek <[hidden email]> wrote:
>>
>> I had the same question previously. It is not very feasible to configure a service user as a delegate on each individual human user. Especially when these human users are constantly added or removed.
>>
>> This is a question for Oak, I believe.
>>
>> Cheers,
>> Alex
>>
>>> On 07.02.2018, at 14:03, Jörg Hoh <[hidden email]> wrote:
>>>
>>> Hi Roy,
>>>
>>> that's indeed good news, as it seems to solve the impersonation usecase. On
>>> the other hand the javadoc is quite clear, that the requirements of the
>>> impersonation process itself come from the underlying repository. I
>>> typically use Oak and the Oak documentation at [1] says that with the
>>> DefaultLoginModule it still requires some kind of prerequisits
>>> ("Impersonation another user will only succeed if the impersonated user is
>>> valid (i.e. exists and is not disabled) *and* the the user associated with
>>> the editing session is allowed to impersonate this user.").
>>>
>>>
>>> Jörg
>>>
>>>
>>>
>>> [1]
>>> https://jackrabbit.apache.org/oak/docs/security/authentication/default.html#impersonation
>>>
>>>
>>>
>>> 2018-02-07 22:50 GMT+01:00 Roy Teeuwen <[hidden email]>:
>>>
>>>> Hey Andres,
>>>>
>>>> We had a similar use case to do impersonation, there is another method for
>>>> that now:
>>>>
>>>> https://sling.apache.org/apidocs/sling10/org/apache/
>>>> sling/jcr/api/SlingRepository.html#impersonateFromService-
>>>> java.lang.String-javax.jcr.Credentials-java.lang.String-
>>>>
>>>> Greets,
>>>> Roy
>>>>
>>>>
>>>> On 7 Feb 2018, at 20:49, Andres Bott <[hidden email]> wrote:
>>>>
>>>> Maybe a solution would be
>>>> - deprecate / remove the method ( to avoid old code to run as admin)
>>>> - rename the class / method and add an info to the log
>>>>
>>>> in this way we make sure that old code gets migrated to service users, and
>>>> the places where it really makes sense to use admin user, the developer
>>>> should be aware of it.
>>>>
>>>> Andres
>>>>
>>>>
>>>> El 2018-02-06 14:09, Bertrand Delacretaz escribió:
>>>>
>>>> On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh <[hidden email]> wrote:
>>>>
>>>> ...Long story short: Is the loginAdministrative() method planned to be
>>>> removed? If yes, we should clearly give best practices and document how it
>>>> can be replaced even in the non-trivial cases. If it's going to stay, we
>>>> should remove the deprecation warning....
>>>>
>>>> I think we need to keep warnings that loginAdmin should be used as
>>>> sparingly as possible.
>>>> And probably provide some examples where it does make sense to use it.
>>>> But deprecation might not be the correct term, as you indicate.
>>>> -Bertrand
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Jörg Hoh,
>>>
>>> http://cqdump.wordpress.com
>>> Twitter: @joerghoh
>>
>


signature.asc (242 bytes) Download Attachment