Re: Deprecation of SlingRepository.loginAdministrative()

[Alexander Klimetschek]

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  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  
>> 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  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 :
>>> 
 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  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  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
Description: Message signed with OpenPGP

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  
> 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  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 :
>> 
>>> 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  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  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
Description: Message signed with OpenPGP

Re: Deprecation of SlingRepository.loginAdministrative()

[Alexander Klimetschek]

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  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 :
> 
>> 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  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  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

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 :

> 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  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  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

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:

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  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  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
Description: Message signed with OpenPGP

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  
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

Re: Deprecation of SlingRepository.loginAdministrative()

[Bertrand Delacretaz]

On Tue, Feb 6, 2018 at 1:02 PM, Jörg Hoh  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