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 <[email protected]> schrieb am Sa. 28. Juli 2018 > um 12:06: > > > On Sat, Jul 28, 2018 at 10:23 AM Carsten Ziegeler <[email protected]> > > 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 > >
