SLING-7613 - un-deprecating loginAdministrative

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

SLING-7613 - un-deprecating loginAdministrative

Robert Munteanu-2
Hi,

Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
to un-deprecate loginAdministrative [3].

Comments/reviews are most welcome, I plan to merge this next Monday.

Thanks,

Robert

[1]: https://issues.apache.org/jira/browse/SLING-7613
[2]: http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
[3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Jason E Bailey-2
I'm good with the deprecation removal, but would like to see some clear guide lines on usage.

- Jason

On Tue, Jul 17, 2018, at 8:55 AM, Robert Munteanu wrote:

> Hi,
>
> Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
> to un-deprecate loginAdministrative [3].
>
> Comments/reviews are most welcome, I plan to merge this next Monday.
>
> Thanks,
>
> Robert
>
> [1]: https://issues.apache.org/jira/browse/SLING-7613
> [2]:
> http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
> [3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

justzzzz
In reply to this post by Robert Munteanu-2
+1 to the idea of removing the deprecation
-0 on the PR

Without the deprecation, how will a developer know that they need to
configure the whitelist? While the deprecation wasn't perfect, at least it
gave the developer the sense that they were doing something which should be
avoided. It is unfortunate that deprecation in Java is such a binary
concept, but it is what it is.

I think we have two choices:

1. Go back to the way things were before -- no deprecation, no whitelist
2. Keep the deprecation and whitelist and improve the JavaDoc

No deprecation and keeping the whitelist just seems like a recipe for
confusion.

Justin

On Tue, Jul 17, 2018 at 8:55 AM Robert Munteanu <[hidden email]> wrote:

> Hi,
>
> Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
> to un-deprecate loginAdministrative [3].
>
> Comments/reviews are most welcome, I plan to merge this next Monday.
>
> Thanks,
>
> Robert
>
> [1]: https://issues.apache.org/jira/browse/SLING-7613
> [2]:
> http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
> [3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
>
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Roy Teeuwen
Hey Justin,

How would this be any different from using the getServiceResourceResolver though? This also needs additional work to actually create the service user and make a service mapping config for it.
Not that I am disagreeing with what you are saying because I think the service user is also a bit too complex sometimes

Greets
Roy

> On 17 Jul 2018, at 15:43, Justin Edelson <[hidden email]> wrote:
>
> +1 to the idea of removing the deprecation
> -0 on the PR
>
> Without the deprecation, how will a developer know that they need to
> configure the whitelist? While the deprecation wasn't perfect, at least it
> gave the developer the sense that they were doing something which should be
> avoided. It is unfortunate that deprecation in Java is such a binary
> concept, but it is what it is.
>
> I think we have two choices:
>
> 1. Go back to the way things were before -- no deprecation, no whitelist
> 2. Keep the deprecation and whitelist and improve the JavaDoc
>
> No deprecation and keeping the whitelist just seems like a recipe for
> confusion.
>
> Justin
>
> On Tue, Jul 17, 2018 at 8:55 AM Robert Munteanu <[hidden email]> wrote:
>
>> Hi,
>>
>> Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
>> to un-deprecate loginAdministrative [3].
>>
>> Comments/reviews are most welcome, I plan to merge this next Monday.
>>
>> Thanks,
>>
>> Robert
>>
>> [1]: https://issues.apache.org/jira/browse/SLING-7613
>> [2]:
>> http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
>> [3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
>>

Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

justzzzz
Hi Roy,
I think Joerg lays out a few scenarios in SLING-7613 where there is a
distinction between loginService* and loginAdministrative. But that's not
really my point :)

All I'm trying to say is that if we are going to continue to have a
whitelist, we need a way to tell the developer that when they use
loginAdministrative some extra step is necessary. To my knowledge,
deprecation is the most universal way to do that.

Regards,
Justin

On Tue, Jul 17, 2018 at 9:45 AM Roy Teeuwen <[hidden email]> wrote:

> Hey Justin,
>
> How would this be any different from using the getServiceResourceResolver
> though? This also needs additional work to actually create the service user
> and make a service mapping config for it.
> Not that I am disagreeing with what you are saying because I think the
> service user is also a bit too complex sometimes
>
> Greets
> Roy
>
> > On 17 Jul 2018, at 15:43, Justin Edelson <[hidden email]>
> wrote:
> >
> > +1 to the idea of removing the deprecation
> > -0 on the PR
> >
> > Without the deprecation, how will a developer know that they need to
> > configure the whitelist? While the deprecation wasn't perfect, at least
> it
> > gave the developer the sense that they were doing something which should
> be
> > avoided. It is unfortunate that deprecation in Java is such a binary
> > concept, but it is what it is.
> >
> > I think we have two choices:
> >
> > 1. Go back to the way things were before -- no deprecation, no whitelist
> > 2. Keep the deprecation and whitelist and improve the JavaDoc
> >
> > No deprecation and keeping the whitelist just seems like a recipe for
> > confusion.
> >
> > Justin
> >
> > On Tue, Jul 17, 2018 at 8:55 AM Robert Munteanu <[hidden email]>
> wrote:
> >
> >> Hi,
> >>
> >> Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
> >> to un-deprecate loginAdministrative [3].
> >>
> >> Comments/reviews are most welcome, I plan to merge this next Monday.
> >>
> >> Thanks,
> >>
> >> Robert
> >>
> >> [1]: https://issues.apache.org/jira/browse/SLING-7613
> >> [2]:
> >>
> http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
> >> [3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Carsten Ziegeler
In reply to this post by Robert Munteanu-2
SlingRepository#loginAdmin shouldn't be used at all.
ResourceResolverFactory is the service to be used.

I think we had a discussion some time back about undeprecating
RRF#loginAdmin and we decided against it. So I think the same arguments
(whatever they were) hold true for SR#loginAdmin.

loginAdmin should not be used by average code and it seems deprecation
is the only vehicle we have that works

Regards

Carsten


Robert Munteanu wrote

> Hi,
>
> Following dev@sling discussions [1] and Jira issue [2] I've filed a PR
> to un-deprecate loginAdministrative [3].
>
> Comments/reviews are most welcome, I plan to merge this next Monday.
>
> Thanks,
>
> Robert
>
> [1]: https://issues.apache.org/jira/browse/SLING-7613
> [2]: http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
> [3]: https://github.com/apache/sling-org-apache-sling-jcr-api/pull/1
>
--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Bertrand Delacretaz
In reply to this post by justzzzz
Hi,

On Tue, Jul 17, 2018 at 1:43 PM Justin Edelson <[hidden email]> wrote:
> ...Without the deprecation, how will a developer know that they need to
> configure the whitelist? While the deprecation wasn't perfect, at least it
> gave the developer the sense that they were doing something which should be
> avoided. It is unfortunate that deprecation in Java is such a binary
> concept, but it is what it is...

I agree with Justin here, I think our intention is to say "do not use
this method unless you really have to and you know what you are doing"
and also "note that you have to whitelist bundles which uses this".

That's not the standard meaning of a deprecated Java method, but as
Justin says we don't want developers to miss that restriction and
deprecation is a workable (and imperfect) way of doing that.

With this in mind I suggest keeping the deprecation, creating a
website page that explains what it actually means and linking to that
page in the javadocs.

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

Re: SLING-7613 - un-deprecating loginAdministrative

Jason E Bailey-2
I may be off base here since I haven't spent much time with service users but couldn't  this be handled by extending the Service User so that for specific services, the user returned is the literal admin user.

i.e. rather then whitelisting the services that can use loginAdministrative the service user that these whitelisted services would get would be the Administrator user.

- Jason

On Thu, Jul 19, 2018, at 5:25 AM, Bertrand Delacretaz wrote:

> Hi,
>
> On Tue, Jul 17, 2018 at 1:43 PM Justin Edelson <[hidden email]> wrote:
> > ...Without the deprecation, how will a developer know that they need to
> > configure the whitelist? While the deprecation wasn't perfect, at least it
> > gave the developer the sense that they were doing something which should be
> > avoided. It is unfortunate that deprecation in Java is such a binary
> > concept, but it is what it is...
>
> I agree with Justin here, I think our intention is to say "do not use
> this method unless you really have to and you know what you are doing"
> and also "note that you have to whitelist bundles which uses this".
>
> That's not the standard meaning of a deprecated Java method, but as
> Justin says we don't want developers to miss that restriction and
> deprecation is a workable (and imperfect) way of doing that.
>
> With this in mind I suggest keeping the deprecation, creating a
> website page that explains what it actually means and linking to that
> page in the javadocs.
>
> -Bertrand
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

justzzzz
If this is technically possible (and I don't see why it isn't), I think
this is a very elegant solution.

On Fri, Jul 27, 2018 at 10:41 AM Jason E Bailey <[hidden email]> wrote:

> I may be off base here since I haven't spent much time with service users
> but couldn't  this be handled by extending the Service User so that for
> specific services, the user returned is the literal admin user.
>
> i.e. rather then whitelisting the services that can use
> loginAdministrative the service user that these whitelisted services would
> get would be the Administrator user.
>
> - Jason
>
> On Thu, Jul 19, 2018, at 5:25 AM, Bertrand Delacretaz wrote:
> > Hi,
> >
> > On Tue, Jul 17, 2018 at 1:43 PM Justin Edelson <[hidden email]>
> wrote:
> > > ...Without the deprecation, how will a developer know that they need to
> > > configure the whitelist? While the deprecation wasn't perfect, at
> least it
> > > gave the developer the sense that they were doing something which
> should be
> > > avoided. It is unfortunate that deprecation in Java is such a binary
> > > concept, but it is what it is...
> >
> > I agree with Justin here, I think our intention is to say "do not use
> > this method unless you really have to and you know what you are doing"
> > and also "note that you have to whitelist bundles which uses this".
> >
> > That's not the standard meaning of a deprecated Java method, but as
> > Justin says we don't want developers to miss that restriction and
> > deprecation is a workable (and imperfect) way of doing that.
> >
> > With this in mind I suggest keeping the deprecation, creating a
> > website page that explains what it actually means and linking to that
> > page in the javadocs.
> >
> > -Bertrand
>
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Jörg Hoh-2
In reply to this post by Jason E Bailey-2
Hi

2018-07-27 16:41 GMT+02:00 Jason E Bailey <[hidden email]>:

> I may be off base here since I haven't spent much time with service users
> but couldn't  this be handled by extending the Service User so that for
> specific services, the user returned is the literal admin user.
>
> i.e. rather then whitelisting the services that can use
> loginAdministrative the service user that these whitelisted services would
> get would be the Administrator user.
>

That means, that instead of the service-user you can configure to receive
the admin-user? I guess, that it won't change much... Instead of creating a
new service-user lazy people will use the admin. One could argue, that it's
still to easy to use an admin session. But harmonizing both approaches
would definitley help, because then a switch from a service-user to an
admin-user and vice-versa would be just a configuration change, but no code
change.

Jörg

--
Cheers,
Jörg Hoh,

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

Re: SLING-7613 - un-deprecating loginAdministrative

Dominik Süß
+1 - instead of whitelisted calls of the loginadmin call the mapping to
admin could be whitelisted. Btw.the very early versions of servicemapping
did allow to map to any user including admin which was used as temporary
bridge until all the initial hiccups with service users were sorted out (at
least by developers aware of that option - just remember because those
admin mappings had thento be removed to be able to eliminate this option.

Cheers
Dominik

Jörg Hoh <[hidden email]> schrieb am Fr. 27. Juli 2018 um
17:17:

> Hi
>
> 2018-07-27 16:41 GMT+02:00 Jason E Bailey <[hidden email]>:
>
> > I may be off base here since I haven't spent much time with service users
> > but couldn't  this be handled by extending the Service User so that for
> > specific services, the user returned is the literal admin user.
> >
> > i.e. rather then whitelisting the services that can use
> > loginAdministrative the service user that these whitelisted services
> would
> > get would be the Administrator user.
> >
>
> That means, that instead of the service-user you can configure to receive
> the admin-user? I guess, that it won't change much... Instead of creating a
> new service-user lazy people will use the admin. One could argue, that it's
> still to easy to use an admin session. But harmonizing both approaches
> would definitley help, because then a switch from a service-user to an
> admin-user and vice-versa would be just a configuration change, but no code
> change.
>
> Jörg
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh
>
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Carsten Ziegeler
I'm not sure if we should go this way. Today you can just look at the
code and you know whether admin is used or not. Hiding this behind the
same api and defering it to configuration makes it very hard to do sane
code checks.

Maybe we should step back and ask what exact problem are we trying to
solve?

Carsten


Dominik Süß wrote

> +1 - instead of whitelisted calls of the loginadmin call the mapping to
> admin could be whitelisted. Btw.the very early versions of servicemapping
> did allow to map to any user including admin which was used as temporary
> bridge until all the initial hiccups with service users were sorted out (at
> least by developers aware of that option - just remember because those
> admin mappings had thento be removed to be able to eliminate this option.
>
> Cheers
> Dominik
>
> Jörg Hoh <[hidden email]> schrieb am Fr. 27. Juli 2018 um
> 17:17:
>
>> Hi
>>
>> 2018-07-27 16:41 GMT+02:00 Jason E Bailey <[hidden email]>:
>>
>>> I may be off base here since I haven't spent much time with service users
>>> but couldn't  this be handled by extending the Service User so that for
>>> specific services, the user returned is the literal admin user.
>>>
>>> i.e. rather then whitelisting the services that can use
>>> loginAdministrative the service user that these whitelisted services
>> would
>>> get would be the Administrator user.
>>>
>>
>> That means, that instead of the service-user you can configure to receive
>> the admin-user? I guess, that it won't change much... Instead of creating a
>> new service-user lazy people will use the admin. One could argue, that it's
>> still to easy to use an admin session. But harmonizing both approaches
>> would definitley help, because then a switch from a service-user to an
>> admin-user and vice-versa would be just a configuration change, but no code
>> change.
>>
>> Jörg
>>
>> --
>> Cheers,
>> Jörg Hoh,
>>
>> http://cqdump.wordpress.com
>> Twitter: @joerghoh
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Georg Henzler-2
I think the initial motivation are the two points in [1]

For "Package installation and deployment." it's
easy enough to define a user with the path he may write
to (this is actually a good exercise).

> To emulate this this with a system user, I have to
> configure every user to allow impersonation from this
> service user

Why don't we allow somehow to configure "*" for who a
service user can impersonate? Should be easy to
implement in oak....

For potential remaining cases (especially in platform code)
it is not nice to have the deprecation warning in the code
I  suppose (think SonarQube etc.). Why don't we introduce
an interface LegitimateAdminSessionUsage with a method
getAdminResolver() that is not deprecated? (I would still
require the LoginAdminWhitelist config). That way we leave
the service user mechanism untouched (I think we should!)
and code in need can use the following:

ResourceResolver adminResourceResolver  =
    ((LegitimateAdminSessionUsage) rrf).getAdminResolver();

Having a new interface makes it easy for code reviews
to grep over the code and immediately see where an
admin session is used. It is enough to document it in
Javadoc, most of the world should not need it/know about it.

-Georg

[1]
http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html



On 2018-07-28 10:23, Carsten Ziegeler wrote:

> I'm not sure if we should go this way. Today you can just look at the
> code and you know whether admin is used or not. Hiding this behind the
> same api and defering it to configuration makes it very hard to do sane
> code checks.
>
> Maybe we should step back and ask what exact problem are we trying to
> solve?
>
> Carsten
>
>
> Dominik Süß wrote
>> +1 - instead of whitelisted calls of the loginadmin call the mapping
>> to
>> admin could be whitelisted. Btw.the very early versions of
>> servicemapping
>> did allow to map to any user including admin which was used as
>> temporary
>> bridge until all the initial hiccups with service users were sorted
>> out (at
>> least by developers aware of that option - just remember because those
>> admin mappings had thento be removed to be able to eliminate this
>> option.
>>
>> Cheers
>> Dominik
>>
>> Jörg Hoh <[hidden email]> schrieb am Fr. 27. Juli 2018
>> um
>> 17:17:
>>
>>> Hi
>>>
>>> 2018-07-27 16:41 GMT+02:00 Jason E Bailey <[hidden email]>:
>>>
>>>> I may be off base here since I haven't spent much time with service
>>>> users
>>>> but couldn't  this be handled by extending the Service User so that
>>>> for
>>>> specific services, the user returned is the literal admin user.
>>>>
>>>> i.e. rather then whitelisting the services that can use
>>>> loginAdministrative the service user that these whitelisted services
>>> would
>>>> get would be the Administrator user.
>>>>
>>>
>>> That means, that instead of the service-user you can configure to
>>> receive
>>> the admin-user? I guess, that it won't change much... Instead of
>>> creating a
>>> new service-user lazy people will use the admin. One could argue,
>>> that it's
>>> still to easy to use an admin session. But harmonizing both
>>> approaches
>>> would definitley help, because then a switch from a service-user to
>>> an
>>> admin-user and vice-versa would be just a configuration change, but
>>> no code
>>> change.
>>>
>>> Jörg
>>>
>>> --
>>> Cheers,
>>> Jörg Hoh,
>>>
>>> http://cqdump.wordpress.com
>>> Twitter: @joerghoh
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Carsten Ziegeler
Well, there are far easier ways to get rid of the deprecation warning
than introducing a new interface to the API.

Adding a comment like NOSONAR (at least that's what I remember it is)
solves that issue.

Regards

Carsten


Georg Henzler wrote

> I think the initial motivation are the two points in [1]
>
> For "Package installation and deployment." it's
> easy enough to define a user with the path he may write
> to (this is actually a good exercise).
>
>> To emulate this this with a system user, I have to
>> configure every user to allow impersonation from this
>> service user
>
> Why don't we allow somehow to configure "*" for who a
> service user can impersonate? Should be easy to
> implement in oak....
>
> For potential remaining cases (especially in platform code)
> it is not nice to have the deprecation warning in the code
> I  suppose (think SonarQube etc.). Why don't we introduce
> an interface LegitimateAdminSessionUsage with a method
> getAdminResolver() that is not deprecated? (I would still
> require the LoginAdminWhitelist config). That way we leave
> the service user mechanism untouched (I think we should!)
> and code in need can use the following:
>
> ResourceResolver adminResourceResolver  =
>    ((LegitimateAdminSessionUsage) rrf).getAdminResolver();
>
> Having a new interface makes it easy for code reviews
> to grep over the code and immediately see where an
> admin session is used. It is enough to document it in
> Javadoc, most of the world should not need it/know about it.
>
> -Georg
>
> [1]
> http://apache-sling.73963.n3.nabble.com/Deprecation-of-SlingRepository-loginAdministrative-td4081024.html
>
>
>
>
> On 2018-07-28 10:23, Carsten Ziegeler wrote:
>> I'm not sure if we should go this way. Today you can just look at the
>> code and you know whether admin is used or not. Hiding this behind the
>> same api and defering it to configuration makes it very hard to do sane
>> code checks.
>>
>> Maybe we should step back and ask what exact problem are we trying to
>> solve?
>>
>> Carsten
>>
>>
>> Dominik Süß wrote
>>> +1 - instead of whitelisted calls of the loginadmin call the mapping to
>>> admin could be whitelisted. Btw.the very early versions of
>>> servicemapping
>>> did allow to map to any user including admin which was used as temporary
>>> bridge until all the initial hiccups with service users were sorted
>>> out (at
>>> least by developers aware of that option - just remember because those
>>> admin mappings had thento be removed to be able to eliminate this
>>> option.
>>>
>>> Cheers
>>> Dominik
>>>
>>> Jörg Hoh <[hidden email]> schrieb am Fr. 27. Juli
>>> 2018 um
>>> 17:17:
>>>
>>>> Hi
>>>>
>>>> 2018-07-27 16:41 GMT+02:00 Jason E Bailey <[hidden email]>:
>>>>
>>>>> I may be off base here since I haven't spent much time with service
>>>>> users
>>>>> but couldn't  this be handled by extending the Service User so that
>>>>> for
>>>>> specific services, the user returned is the literal admin user.
>>>>>
>>>>> i.e. rather then whitelisting the services that can use
>>>>> loginAdministrative the service user that these whitelisted services
>>>> would
>>>>> get would be the Administrator user.
>>>>>
>>>>
>>>> That means, that instead of the service-user you can configure to
>>>> receive
>>>> the admin-user? I guess, that it won't change much... Instead of
>>>> creating a
>>>> new service-user lazy people will use the admin. One could argue,
>>>> that it's
>>>> still to easy to use an admin session. But harmonizing both approaches
>>>> would definitley help, because then a switch from a service-user to an
>>>> admin-user and vice-versa would be just a configuration change, but
>>>> no code
>>>> change.
>>>>
>>>> Jörg
>>>>
>>>> --
>>>> Cheers,
>>>> Jörg Hoh,
>>>>
>>>> http://cqdump.wordpress.com
>>>> Twitter: @joerghoh
>>>>
>>>
--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Bertrand Delacretaz
In reply to this post by Carsten Ziegeler
On Sat, Jul 28, 2018 at 10:23 AM Carsten Ziegeler <[hidden email]> wrote:
> ...Today you can just look at the
> code and you know whether admin is used or not...

I share this concern, any mechanism that magically makes something
admin is dangerous as it can easily be overlooked.

If changes are really needed I think they should keep the current
"it's obvious what admin is" visibility.

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

Re: SLING-7613 - un-deprecating loginAdministrative

Dominik Süß
I understand this position and can emphasize while it may lead to a wrong
sense of security. Even service users require severe attention wrt their
permissions and can be similarly dangerous if they can write code into
executable locations (and expand the attack by being able to potentially
use loginadmin).

I personally still think we should get an option to retrieve a session
and/or resourceResolver where we further constrain  what the user can do in
this particular session - processing malicious data in such a session
couldn’t do harm outside of the case for which the session is built.

Maybe someone with a deeper security aspect background of the oak team can
share about their thoughts of how to deal with those cases best.

Cheers
Dominik

Bertrand Delacretaz <[hidden email]> schrieb am Sa. 28. Juli 2018
um 12:06:

> On Sat, Jul 28, 2018 at 10:23 AM Carsten Ziegeler <[hidden email]>
> wrote:
> > ...Today you can just look at the
> > code and you know whether admin is used or not...
>
> I share this concern, any mechanism that magically makes something
> admin is dangerous as it can easily be overlooked.
>
> If changes are really needed I think they should keep the current
> "it's obvious what admin is" visibility.
>
> -Bertrand
>
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Jason E Bailey-2
Maybe a hybrid approach?

The current problem as I understand it, is that there is a need at times for an admin session. The current way to get an admin session allows access to that user from anywhere that code can be written, from any bundle, or JSP.  Service users are better because they can be linked to a Service, constrained, and you can't access them from a script.

Modify the Service user to require an explicit request for the Admin user, however that Admin user is restricted by configuration to what services can call it.

1. It's now clear in the code when an Admin session is being requested.
2. The Admin session can be restricted to specific services, providing a level of security
3. Admin session can not be accessed from a script at all, and you would need to access a service instead.
4. We can remove or throw unsupported exceptions on the older direct methods of accessing the admin session

- Jason

On Sat, Jul 28, 2018, at 1:27 PM, Dominik Süß wrote:

> I understand this position and can emphasize while it may lead to a wrong
> sense of security. Even service users require severe attention wrt their
> permissions and can be similarly dangerous if they can write code into
> executable locations (and expand the attack by being able to potentially
> use loginadmin).
>
> I personally still think we should get an option to retrieve a session
> and/or resourceResolver where we further constrain  what the user can do in
> this particular session - processing malicious data in such a session
> couldn’t do harm outside of the case for which the session is built.
>
> Maybe someone with a deeper security aspect background of the oak team can
> share about their thoughts of how to deal with those cases best.
>
> Cheers
> Dominik
>
> Bertrand Delacretaz <[hidden email]> schrieb am Sa. 28. Juli 2018
> um 12:06:
>
> > On Sat, Jul 28, 2018 at 10:23 AM Carsten Ziegeler <[hidden email]>
> > wrote:
> > > ...Today you can just look at the
> > > code and you know whether admin is used or not...
> >
> > I share this concern, any mechanism that magically makes something
> > admin is dangerous as it can easily be overlooked.
> >
> > If changes are really needed I think they should keep the current
> > "it's obvious what admin is" visibility.
> >
> > -Bertrand
> >
Reply | Threaded
Open this post in threaded view
|

Re: SLING-7613 - un-deprecating loginAdministrative

Robert Munteanu-2
In reply to this post by Robert Munteanu-2
On Tue, 2018-07-17 at 14:55 +0200, Robert Munteanu wrote:
> Comments/reviews are most welcome, I plan to merge this next Monday.

It's clear from the discussions that there is no consensus on whether
this is a good thing or not. I will drop this PR and close the Jira as
WONTFIX.

There are some good ideas that popped in the thread, but I believe they
deserve separate attention.

Thanks all for the discussion,

Robert