New Impersonate Feature : OFBIZ-10515

[Gil Portenseigne]

Hello !

I would like to introduce to you a new feature, i already talked about some
time ago (last year?). We needed it for one of our customer, that is
using it for some time and is very happy with it (like we are).

Indeed this impersonation feature comes to be very useful when we need
to validate some behaviour or to assist a user in production without
asking for its credential. It's became so easy to use that even in
preproduction/integration environment we use it daily to impersonate
specific configured userlogin without trying to remember the password...

It's kinda basic, a new permission is created and can be granted to an
authorized user, that will be offered a way to select a userlogin to
impersonate.

It's a common feature that can be found for example in Gitlab.

If you wanna try it out it's available here :
https://issues.apache.org/jira/browse/OFBIZ-10515

Feedback are welcomed :), although i'll be partly offline next week.

Looking forward reading you !

Gil

[Rajesh Mallah]

This feature has valid use cases.
+1

On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
[hidden email]> wrote:

> Hello !
>
> I would like to introduce to you a new feature, i already talked about some
> time ago (last year?). We needed it for one of our customer, that is
> using it for some time and is very happy with it (like we are).
>
> Indeed this impersonation feature comes to be very useful when we need
> to validate some behaviour or to assist a user in production without
> asking for its credential. It's became so easy to use that even in
> preproduction/integration environment we use it daily to impersonate
> specific configured userlogin without trying to remember the password...
>
> It's kinda basic, a new permission is created and can be granted to an
> authorized user, that will be offered a way to select a userlogin to
> impersonate.
>
> It's a common feature that can be found for example in Gitlab.
>
> If you wanna try it out it's available here :
> https://issues.apache.org/jira/browse/OFBIZ-10515
>
> Feedback are welcomed :), although i'll be partly offline next week.
>
> Looking forward reading you !
>
> Gil
>

[Shi Jinghai-3]

+1.

Now we can hold a cosplay party in OFBiz, right? :)


-----邮件原件-----
发件人: Gil Portenseigne [mailto:[hidden email]]
发送时间: 2018年8月11日 4:00
收件人: dev OFBiz
主题: New Impersonate Feature : OFBIZ-10515

Hello !

I would like to introduce to you a new feature, i already talked about some
time ago (last year?). We needed it for one of our customer, that is
using it for some time and is very happy with it (like we are).

Indeed this impersonation feature comes to be very useful when we need
to validate some behaviour or to assist a user in production without
asking for its credential. It's became so easy to use that even in
preproduction/integration environment we use it daily to impersonate
specific configured userlogin without trying to remember the password...

It's kinda basic, a new permission is created and can be granted to an
authorized user, that will be offered a way to select a userlogin to
impersonate.

It's a common feature that can be found for example in Gitlab.

If you wanna try it out it's available here :
https://issues.apache.org/jira/browse/OFBIZ-10515

Feedback are welcomed :), although i'll be partly offline next week.

Looking forward reading you !

Gil

[taher]

Very nice feature, and a lovely addition.

Before we go ahead and commit it, can we ensure that security will be
okay? I noted that you had permission checks around the service
definition and UI for IMPERSONATE_ADMIN. Are we comfortable that we
didn't create any loop holes, especially around the login worker? In
other words, do you feel comfortable that we tightened all screws
around that? The reason I ask is because I note that you can
impersonate and then get back to your regular user. Where is the
session stored? Is this a servlet session variable? Is it secured?
On Sun, Aug 12, 2018 at 6:22 AM Shi Jinghai <[hidden email]> wrote:

>
> +1.
>
> Now we can hold a cosplay party in OFBiz, right? :)
>
>
> -----邮件原件-----
> 发件人: Gil Portenseigne [mailto:[hidden email]]
> 发送时间: 2018年8月11日 4:00
> 收件人: dev OFBiz
> 主题: New Impersonate Feature : OFBIZ-10515
>
> Hello !
>
> I would like to introduce to you a new feature, i already talked about some
> time ago (last year?). We needed it for one of our customer, that is
> using it for some time and is very happy with it (like we are).
>
> Indeed this impersonation feature comes to be very useful when we need
> to validate some behaviour or to assist a user in production without
> asking for its credential. It's became so easy to use that even in
> preproduction/integration environment we use it daily to impersonate
> specific configured userlogin without trying to remember the password...
>
> It's kinda basic, a new permission is created and can be granted to an
> authorized user, that will be offered a way to select a userlogin to
> impersonate.
>
> It's a common feature that can be found for example in Gitlab.
>
> If you wanna try it out it's available here :
> https://issues.apache.org/jira/browse/OFBIZ-10515
>
> Feedback are welcomed :), although i'll be partly offline next week.
>
> Looking forward reading you !
>
> Gil

[Zhang Wei]

+1
________________________________
发件人: Rajesh Mallah <[hidden email]>
发送时间: 2018年8月11日 11:10
收件人: [hidden email]
主题: Re: New Impersonate Feature : OFBIZ-10515

This feature has valid use cases.
+1

On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
[hidden email]> wrote:

> Hello !
>
> I would like to introduce to you a new feature, i already talked about some
> time ago (last year?). We needed it for one of our customer, that is
> using it for some time and is very happy with it (like we are).
>
> Indeed this impersonation feature comes to be very useful when we need
> to validate some behaviour or to assist a user in production without
> asking for its credential. It's became so easy to use that even in
> preproduction/integration environment we use it daily to impersonate
> specific configured userlogin without trying to remember the password...
>
> It's kinda basic, a new permission is created and can be granted to an
> authorized user, that will be offered a way to select a userlogin to
> impersonate.
>
> It's a common feature that can be found for example in Gitlab.
>
> If you wanna try it out it's available here :
> https://issues.apache.org/jira/browse/OFBIZ-10515
>
> Feedback are welcomed :), although i'll be partly offline next week.
>
> Looking forward reading you !
>
> Gil
>

[Nicolas Malin-2]

Hello,

Gil is currently in vacation but I can answer :)

On 12/08/2018 10:21, Taher Alkhateeb wrote:
> Very nice feature, and a lovely addition.
>
> Before we go ahead and commit it, can we ensure that security will be
> okay?
I'm hoping ! because it's deployed on production site
>   I noted that you had permission checks around the service
> definition and UI for IMPERSONATE_ADMIN. Are we comfortable that we
> didn't create any loop holes, especially around the login worker? In
> other words, do you feel comfortable that we tightened all screws
> around that?
When you impersonate an user, you store your current userLogin in
session to originUserLogin and replace the userLogin with the user
spotted. You keep your session and use the usurpation only when
alongside security control and functional environment that analyze the
current userLogin. When you restore your login, the impersonate user is
removed from session and the originUserLogin is restored to userLogin.

For the loops and security, you can't impersonate yourself, you can't
impersonate when impersonation is enable and you can't impersonate a
user with more security permission than you.

Maybe I can see two security improvements :
* When impersonate we can create an hash with the originUserLogin,
impersonateUserLogin and the impersonate started date to be sure that
the impersonate security context doesn't change
* We can change the impersonnate userLogin.currentPassword hash on the
fly when loading it in context if we have fear to a password hash
collect by the user who have the impersonate permission

Nicolas

>   The reason I ask is because I note that you can
> impersonate and then get back to your regular user. Where is the
> session stored? Is this a servlet session variable? Is it secured?
> On Sun, Aug 12, 2018 at 6:22 AM Shi Jinghai <[hidden email]> wrote:
>> +1.
>>
>> Now we can hold a cosplay party in OFBiz, right? :)
>>
>>
>> -----邮件原件-----
>> 发件人: Gil Portenseigne [mailto:[hidden email]]
>> 发送时间: 2018年8月11日 4:00
>> 收件人: dev OFBiz
>> 主题: New Impersonate Feature : OFBIZ-10515
>>
>> Hello !
>>
>> I would like to introduce to you a new feature, i already talked about some
>> time ago (last year?). We needed it for one of our customer, that is
>> using it for some time and is very happy with it (like we are).
>>
>> Indeed this impersonation feature comes to be very useful when we need
>> to validate some behaviour or to assist a user in production without
>> asking for its credential. It's became so easy to use that even in
>> preproduction/integration environment we use it daily to impersonate
>> specific configured userlogin without trying to remember the password...
>>
>> It's kinda basic, a new permission is created and can be granted to an
>> authorized user, that will be offered a way to select a userlogin to
>> impersonate.
>>
>> It's a common feature that can be found for example in Gitlab.
>>
>> If you wanna try it out it's available here :
>> https://issues.apache.org/jira/browse/OFBIZ-10515
>>
>> Feedback are welcomed :), although i'll be partly offline next week.
>>
>> Looking forward reading you !
>>
>> Gil

[Pierre Smits-3]

Impressive...

This seems to be an in-OFBiz equivalent of an OS take-over tool like
Microsoft's Remote Desktop. The business case (and use cases) are explained
insufficiently in this thread or in the ticket ([1]) why incorporating this
in the repo should be favourable over having the adopting business
implement implement the OS take-over tool. What I feel missing here (and in
the ticket) is the reference to the previous thread, which might explain
the business case. I suggest to have a link to this thread also in the
ticket

Based on a cursory review of the patch, it is lacking serious aspects that
will boost the confidence of any business adopter that this feature will
not jeopardise their business operations. As it is now, I find the patch to
basic to be committed to the repo and be included in any new release.

As I see it it allows anybody with the IMPERSONATE_ADMIN permission take
over any other ID and perform actions under that ID at anytime. I did not
see any functionality (I am spitballing here) that:

   1. would exclude any particular ID from being taken over (as a default
   configuration)
   2. would allow a user to disable the feature for their own account
   (overriding the default permission of impersonation)
   3. would allow a user to explicitly allow its ID to be taken over by
   someone else, AND limit it for a specific amount of time (overriding aspect
   #2 above).
   4. would prohibit the impersonator to take over an ID when the user of
   the ID is NOT logged in (which should be an additional default aspect).

This feature seems 'impersonator' driven as the permission would not be on
a case-by-case scenario, but rather on a semi-permanent permission
assignment and by a user who has the - technical -  permission to set such
a permission.

What I furthermore feel lacking or underdeveloped is the audit and logging
trail regarding this feature. Nowhere can be seen what actions (for the
authentic ID) have been undertaken by the impersonator while the
impersonation was in progress. Neither in logfiles, nor in screens in the
Partymgr component (e.g. for the user to see).

I advise the community to be very careful to commit this, without
consideration of the above, into the repo.


[1] https://issues.apache.org/jira/browse/OFBIZ-10515


Best regards,

Pierre Smits

Apache Trafodion <https://trafodion.apache.org>, Vice President
Apache Directory <https://directory.apache.org>, PMC Member
Apache Incubator <https://incubator.apache.org>, committer
Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
Apache Steve <https://steve.apache.org>, committer

On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:

> +1
> ________________________________
> 发件人: Rajesh Mallah <[hidden email]>
> 发送时间: 2018年8月11日 11:10
> 收件人: [hidden email]
> 主题: Re: New Impersonate Feature : OFBIZ-10515
>
> This feature has valid use cases.
> +1
>
> On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
> [hidden email]> wrote:
>
> > Hello !
> >
> > I would like to introduce to you a new feature, i already talked about
> some
> > time ago (last year?). We needed it for one of our customer, that is
> > using it for some time and is very happy with it (like we are).
> >
> > Indeed this impersonation feature comes to be very useful when we need
> > to validate some behaviour or to assist a user in production without
> > asking for its credential. It's became so easy to use that even in
> > preproduction/integration environment we use it daily to impersonate
> > specific configured userlogin without trying to remember the password...
> >
> > It's kinda basic, a new permission is created and can be granted to an
> > authorized user, that will be offered a way to select a userlogin to
> > impersonate.
> >
> > It's a common feature that can be found for example in Gitlab.
> >
> > If you wanna try it out it's available here :
> > https://issues.apache.org/jira/browse/OFBIZ-10515
> >
> > Feedback are welcomed :), although i'll be partly offline next week.
> >
> > Looking forward reading you !
> >
> > Gil
> >
>

[taher]

One idea that comes to my mind which might be useful is that we add a
flag in general.properties that by default enables this feature, and
we can then specify in the documentation that to secure OFBiz we need
to disable this feature so that it can be used in development but
disabled in production for people who prefer to be on the safe side. I
also like the suggestions from Pierre on perhaps having some kind of
audit trail, just like we have a log of party visits, we can have a
log of impersonation visits for example.

Another idea, is perhaps to avoid completely persisting the session
into the system. In other words, once I impersonate some user, it's
done, I AM that user and I cannot go back. I have to log out and log
back in to access the system again as an admin. That might be a bit
more secure because we don't touch the session data.

All food for thought, and I appreciate getting more feedback from the community.
On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits <[hidden email]> wrote:

>
> Impressive...
>
> This seems to be an in-OFBiz equivalent of an OS take-over tool like
> Microsoft's Remote Desktop. The business case (and use cases) are explained
> insufficiently in this thread or in the ticket ([1]) why incorporating this
> in the repo should be favourable over having the adopting business
> implement implement the OS take-over tool. What I feel missing here (and in
> the ticket) is the reference to the previous thread, which might explain
> the business case. I suggest to have a link to this thread also in the
> ticket
>
> Based on a cursory review of the patch, it is lacking serious aspects that
> will boost the confidence of any business adopter that this feature will
> not jeopardise their business operations. As it is now, I find the patch to
> basic to be committed to the repo and be included in any new release.
>
> As I see it it allows anybody with the IMPERSONATE_ADMIN permission take
> over any other ID and perform actions under that ID at anytime. I did not
> see any functionality (I am spitballing here) that:
>
>    1. would exclude any particular ID from being taken over (as a default
>    configuration)
>    2. would allow a user to disable the feature for their own account
>    (overriding the default permission of impersonation)
>    3. would allow a user to explicitly allow its ID to be taken over by
>    someone else, AND limit it for a specific amount of time (overriding aspect
>    #2 above).
>    4. would prohibit the impersonator to take over an ID when the user of
>    the ID is NOT logged in (which should be an additional default aspect).
>
> This feature seems 'impersonator' driven as the permission would not be on
> a case-by-case scenario, but rather on a semi-permanent permission
> assignment and by a user who has the - technical -  permission to set such
> a permission.
>
> What I furthermore feel lacking or underdeveloped is the audit and logging
> trail regarding this feature. Nowhere can be seen what actions (for the
> authentic ID) have been undertaken by the impersonator while the
> impersonation was in progress. Neither in logfiles, nor in screens in the
> Partymgr component (e.g. for the user to see).
>
> I advise the community to be very careful to commit this, without
> consideration of the above, into the repo.
>
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-10515
>
>
> Best regards,
>
> Pierre Smits
>
> Apache Trafodion <https://trafodion.apache.org>, Vice President
> Apache Directory <https://directory.apache.org>, PMC Member
> Apache Incubator <https://incubator.apache.org>, committer
> Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
> Apache Steve <https://steve.apache.org>, committer
>
> On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
>
> > +1
> > ________________________________
> > 发件人: Rajesh Mallah <[hidden email]>
> > 发送时间: 2018年8月11日 11:10
> > 收件人: [hidden email]
> > 主题: Re: New Impersonate Feature : OFBIZ-10515
> >
> > This feature has valid use cases.
> > +1
> >
> > On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
> > [hidden email]> wrote:
> >
> > > Hello !
> > >
> > > I would like to introduce to you a new feature, i already talked about
> > some
> > > time ago (last year?). We needed it for one of our customer, that is
> > > using it for some time and is very happy with it (like we are).
> > >
> > > Indeed this impersonation feature comes to be very useful when we need
> > > to validate some behaviour or to assist a user in production without
> > > asking for its credential. It's became so easy to use that even in
> > > preproduction/integration environment we use it daily to impersonate
> > > specific configured userlogin without trying to remember the password...
> > >
> > > It's kinda basic, a new permission is created and can be granted to an
> > > authorized user, that will be offered a way to select a userlogin to
> > > impersonate.
> > >
> > > It's a common feature that can be found for example in Gitlab.
> > >
> > > If you wanna try it out it's available here :
> > > https://issues.apache.org/jira/browse/OFBIZ-10515
> > >
> > > Feedback are welcomed :), although i'll be partly offline next week.
> > >
> > > Looking forward reading you !
> > >
> > > Gil
> > >
> >

[Nicolas Malin-2]

Hello,
On 13/08/2018 10:09, Pierre Smits wrote:

> Impressive...
>
> This seems to be an in-OFBiz equivalent of an OS take-over tool like
> Microsoft's Remote Desktop. The business case (and use cases) are explained
> insufficiently in this thread or in the ticket ([1]) why incorporating this
> in the repo should be favourable over having the adopting business
> implement implement the OS take-over tool. What I feel missing here (and in
> the ticket) is the reference to the previous thread, which might explain
> the business case. I suggest to have a link to this thread also in the
> ticket

The feature haven't the same goal than an OS take-over tool, but just on
the same aspect you can escape problematic like system incompatibility
and time zone.
All is embedded in OFBiz with tracking. And in other time, like an OS
take-over tool you can't use it to trainyour end user. For this part
it's better to use a WebRTC client.

I can give you the business case from our own feedback on a B2B
ecommerce platform context:
  * On technical aspect
  ** Give the opportunity for technical administrator to take the lead
on user account toreproduce front side error. This help to spot quickly
the problem and save precious time for the resolution.
  * On functional aspect :
  ** Help the account validation after is creation. A front side admin
can simulate an account just created to ensure that all configuration
are done before activation
  ** During big order, if a functional problem raise, a front side admin
can reload the saved cart to finalize it
  ** To avoid reveiving login information (including password) from the
final user in a non encrypted email (It's not a joke :/ )
  * On QA aspect :
  ** on QA platform, the QA team can use real account to realize their
controls without pass by a password reinitialisation on each need
account at each QA database updated by production database.

> Based on a cursory review of the patch, it is lacking serious aspects that
> will boost the confidence of any business adopter that this feature will
> not jeopardise their business operations. As it is now, I find the patch to
> basic to be committed to the repo and be included in any new release.
>
> As I see it it allows anybody with the IMPERSONATE_ADMIN permission take
> over any other ID and perform actions under that ID at anytime. I did not
> see any functionality (I am spitballing here) that:
>
>     1. would exclude any particular ID from being taken over (as a default
>     configuration)
>     2. would allow a user to disable the feature for their own account
>     (overriding the default permission of impersonation)
>     3. would allow a user to explicitly allow its ID to be taken over by
>     someone else, AND limit it for a specific amount of time (overriding aspect
>     #2 above).
>     4. would prohibit the impersonator to take over an ID when the user of
>     the ID is NOT logged in (which should be an additional default aspect).
>
> This feature seems 'impersonator' driven as the permission would not be on
> a case-by-case scenario, but rather on a semi-permanent permission
> assignment and by a user who has the - technical -  permission to set such
> a permission.

We keptin mind that IMPERSONATE_ADMIN is a high level permission, given
to high level user on the platform or business process.
A user with this permission can't impersonate an other user with more
permissions than him. This is missing on the latest patch and need to be
updated.
IMPERSONATE_ADMIN is a permission so only OFBiz administrator can assign
it to an user (by the permission SECURITY).

I understand your fear to have a high level user that surpass their
rights and use it to damagesome process. We startedwith the idea that
all high level user and OFBiz administrator are trusted peoples, and if
not,maybe we need to track all actions in webtools because currently
with permission ENTITY_MAINT this feature isn't needed.
Most seriously, I see interesting improvement in your remarks that we
shouldnever had two actives sessions on impersonate user. Like this when
a user impersonate an other he will be logged out with an error "You are
currently impersonated by XXX" and he can't login during the
impersonation time. All operations realized during this time can be
associate to the impersonation.
> What I furthermore feel lacking or underdeveloped is the audit and logging
> trail regarding this feature. Nowhere can be seen what actions (for the
> authentic ID) have been undertaken by the impersonator while the
> impersonation was in progress. Neither in logfiles, nor in screens in the
> Partymgr component (e.g. for the user to see).
>
> I advise the community to be very careful to commit this, without
> consideration of the above, into the repo.

With the idea to enable/disable impersonate, we can just manage it with
the permission. If we want, we can load ittoFULLADMIN/SUPER permission
groupotherwise remove this permission. So simple issue would be to
include this permission only on demo data and not seed data.

Cheers,
Nicolas

>
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-10515
>
>
> Best regards,
>
> Pierre Smits
>
> Apache Trafodion <https://trafodion.apache.org>, Vice President
> Apache Directory <https://directory.apache.org>, PMC Member
> Apache Incubator <https://incubator.apache.org>, committer
> Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
> Apache Steve <https://steve.apache.org>, committer
>
> On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
>
>> +1
>> ________________________________
>> 发件人: Rajesh Mallah <[hidden email]>
>> 发送时间: 2018年8月11日 11:10
>> 收件人: [hidden email]
>> 主题: Re: New Impersonate Feature : OFBIZ-10515
>>
>> This feature has valid use cases.
>> +1
>>
>> On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
>> [hidden email]> wrote:
>>
>>> Hello !
>>>
>>> I would like to introduce to you a new feature, i already talked about
>> some
>>> time ago (last year?). We needed it for one of our customer, that is
>>> using it for some time and is very happy with it (like we are).
>>>
>>> Indeed this impersonation feature comes to be very useful when we need
>>> to validate some behaviour or to assist a user in production without
>>> asking for its credential. It's became so easy to use that even in
>>> preproduction/integration environment we use it daily to impersonate
>>> specific configured userlogin without trying to remember the password...
>>>
>>> It's kinda basic, a new permission is created and can be granted to an
>>> authorized user, that will be offered a way to select a userlogin to
>>> impersonate.
>>>
>>> It's a common feature that can be found for example in Gitlab.
>>>
>>> If you wanna try it out it's available here :
>>> https://issues.apache.org/jira/browse/OFBIZ-10515
>>>
>>> Feedback are welcomed :), although i'll be partly offline next week.
>>>
>>> Looking forward reading you !
>>>
>>> Gil
>>>

[Gil Portenseigne]

Hello !

I am back and glad to have so many feedback :)

Since Nicolas already answered, i'll add some precisions and opinions
inline.
Le mardi 14 août 2018 à 18:17:14 (+0200), Nicolas Malin a écrit :
> Hello,
> On 13/08/2018 10:09, Pierre Smits wrote:
> > Impressive...
> >
[...]
> The feature haven't the same goal than an OS take-over tool, but just on the
> same aspect you can escape problematic like system incompatibility and time
> zone.
> All is embedded in OFBiz with tracking. And in other time, like an OS
> take-over tool you can't use it to trainyour end user. For this part it's
> better to use a WebRTC client.
+1 it's not a feature to have access to the client computer. It is a
feature that OFBiz could offer to impersonate and see through the eyes
of another userLogin.

I did not recover the previous thread, but I remember that was a basic
proposal before the implementation. Nicolas answer did offer you use cases, i
hope that will be enough for you to understand the need of such a feature
:).
[...]
> IMPERSONATE_ADMIN is a permission so only OFBiz administrator can assign it
> to an user (by the permission SECURITY).
+1 : that's a high level permission, so to grant it to a user you need
to a trusted admin :), and should be granted to trusted users ! Keep in
mind that is an administration tool, and should be used in such aspect.

Giving control to all user to the configuration of the possible
impersonation of their login is quite strange to me, i do not grasp this
need, could you elaborate ?

>
> I understand your fear to have a high level user that surpass their rights
> and use it to damagesome process. We startedwith the idea that all high
> level user and OFBiz administrator are trusted peoples, and if not,maybe we
> need to track all actions in webtools because currently with permission
> ENTITY_MAINT this feature isn't needed.
> Most seriously, I see interesting improvement in your remarks that we
> shouldnever had two actives sessions on impersonate user. Like this when a
> user impersonate an other he will be logged out with an error "You are
> currently impersonated by XXX" and he can't login during the impersonation
> time. All operations realized during this time can be associate to the
> impersonation.

This idea is interesting in production environement to ensure that all
action made during a time frame is done by the user impersonating. But
this should be desactivable for non-production environment.

> > What I furthermore feel lacking or underdeveloped is the audit and logging
> > trail regarding this feature. Nowhere can be seen what actions (for the
> > authentic ID) have been undertaken by the impersonator while the
> > impersonation was in progress. Neither in logfiles, nor in screens in the
> > Partymgr component (e.g. for the user to see).
The above proposal should help the audit of impersonated user in
production environment. Since impersonation period is stored, and login
desactivated during this period, everything done during it belong to the
impersonator !
> >
> > I advise the community to be very careful to commit this, without
> > consideration of the above, into the repo.

Thanks for your feedback, consideration is here :), let's build a good
secured feature as a community !

I hope you find this feature interesting ? Reading you, i find out that
no documentation is provided yet with this feature, we need to elaborate
one, that will help up introducing it to business adopter and ‘boost
their confidence’ !

Regards,

Gil

[Gil Portenseigne]

Hello Taher,

Thanks for your ideas, i think that had helped making it pop into
Nicolas answer to Pierre (that i just annoted).

I hope the idea, that seem a mix of yours could be good enough, a property that :
* by default allow any impersonation to be done in non-preproduction env,
 without logging out the user. (less security requirement)
* else, impersonation will logout the user impersonated, and restrict
 impersonation to one only for this user, during impersonation time.

The audit could be done in UserLoginHistory entity, storing
impersonation period.

Regards

Gil

Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :

> One idea that comes to my mind which might be useful is that we add a
> flag in general.properties that by default enables this feature, and
> we can then specify in the documentation that to secure OFBiz we need
> to disable this feature so that it can be used in development but
> disabled in production for people who prefer to be on the safe side. I
> also like the suggestions from Pierre on perhaps having some kind of
> audit trail, just like we have a log of party visits, we can have a
> log of impersonation visits for example.
>
> Another idea, is perhaps to avoid completely persisting the session
> into the system. In other words, once I impersonate some user, it's
> done, I AM that user and I cannot go back. I have to log out and log
> back in to access the system again as an admin. That might be a bit
> more secure because we don't touch the session data.
>
> All food for thought, and I appreciate getting more feedback from the community.
> On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits <[hidden email]> wrote:
> >
> > Impressive...
> >
> > This seems to be an in-OFBiz equivalent of an OS take-over tool like
> > Microsoft's Remote Desktop. The business case (and use cases) are explained
> > insufficiently in this thread or in the ticket ([1]) why incorporating this
> > in the repo should be favourable over having the adopting business
> > implement implement the OS take-over tool. What I feel missing here (and in
> > the ticket) is the reference to the previous thread, which might explain
> > the business case. I suggest to have a link to this thread also in the
> > ticket
> >
> > Based on a cursory review of the patch, it is lacking serious aspects that
> > will boost the confidence of any business adopter that this feature will
> > not jeopardise their business operations. As it is now, I find the patch to
> > basic to be committed to the repo and be included in any new release.
> >
> > As I see it it allows anybody with the IMPERSONATE_ADMIN permission take
> > over any other ID and perform actions under that ID at anytime. I did not
> > see any functionality (I am spitballing here) that:
> >
> >    1. would exclude any particular ID from being taken over (as a default
> >    configuration)
> >    2. would allow a user to disable the feature for their own account
> >    (overriding the default permission of impersonation)
> >    3. would allow a user to explicitly allow its ID to be taken over by
> >    someone else, AND limit it for a specific amount of time (overriding aspect
> >    #2 above).
> >    4. would prohibit the impersonator to take over an ID when the user of
> >    the ID is NOT logged in (which should be an additional default aspect).
> >
> > This feature seems 'impersonator' driven as the permission would not be on
> > a case-by-case scenario, but rather on a semi-permanent permission
> > assignment and by a user who has the - technical -  permission to set such
> > a permission.
> >
> > What I furthermore feel lacking or underdeveloped is the audit and logging
> > trail regarding this feature. Nowhere can be seen what actions (for the
> > authentic ID) have been undertaken by the impersonator while the
> > impersonation was in progress. Neither in logfiles, nor in screens in the
> > Partymgr component (e.g. for the user to see).
> >
> > I advise the community to be very careful to commit this, without
> > consideration of the above, into the repo.
> >
> >
> > [1] https://issues.apache.org/jira/browse/OFBIZ-10515
> >
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > Apache Trafodion <https://trafodion.apache.org>, Vice President
> > Apache Directory <https://directory.apache.org>, PMC Member
> > Apache Incubator <https://incubator.apache.org>, committer
> > Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
> > Apache Steve <https://steve.apache.org>, committer
> >
> > On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
> >
> > > +1
> > > ________________________________
> > > 发件人: Rajesh Mallah <[hidden email]>
> > > 发送时间: 2018年8月11日 11:10
> > > 收件人: [hidden email]
> > > 主题: Re: New Impersonate Feature : OFBIZ-10515
> > >
> > > This feature has valid use cases.
> > > +1
> > >
> > > On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
> > > [hidden email]> wrote:
> > >
> > > > Hello !
> > > >
> > > > I would like to introduce to you a new feature, i already talked about
> > > some
> > > > time ago (last year?). We needed it for one of our customer, that is
> > > > using it for some time and is very happy with it (like we are).
> > > >
> > > > Indeed this impersonation feature comes to be very useful when we need
> > > > to validate some behaviour or to assist a user in production without
> > > > asking for its credential. It's became so easy to use that even in
> > > > preproduction/integration environment we use it daily to impersonate
> > > > specific configured userlogin without trying to remember the password...
> > > >
> > > > It's kinda basic, a new permission is created and can be granted to an
> > > > authorized user, that will be offered a way to select a userlogin to
> > > > impersonate.
> > > >
> > > > It's a common feature that can be found for example in Gitlab.
> > > >
> > > > If you wanna try it out it's available here :
> > > > https://issues.apache.org/jira/browse/OFBIZ-10515
> > > >
> > > > Feedback are welcomed :), although i'll be partly offline next week.
> > > >
> > > > Looking forward reading you !
> > > >
> > > > Gil
> > > >
> > >

[Jacques Le Roux]

Le 20/08/2018 à 10:50, Gil Portenseigne a écrit :
> I hope you find this feature interesting ? Reading you, i find out that
> no documentation is provided yet with this feature, we need to elaborate
> one, that will help up introducing it to business adopter and ‘boost
> their confidence’ !
>
> Regards,
>
> Gil
A big +1 :)

Jacques

[taher]

I don't have a strong opinion on this, and I am open. My personal
preference is pehaps to just 'login as' instead of impersonate with normal
user login history. The reason for my preference is having the least amount
of code written and least security worries. I find the impersonate feature
also lovely and quite useful. So both directions are okay for me.

On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne <[hidden email]>
wrote:

> Hello Taher,
>
> Thanks for your ideas, i think that had helped making it pop into
> Nicolas answer to Pierre (that i just annoted).
>
> I hope the idea, that seem a mix of yours could be good enough, a property
> that :
> * by default allow any impersonation to be done in non-preproduction env,
>  without logging out the user. (less security requirement)
> * else, impersonation will logout the user impersonated, and restrict
>  impersonation to one only for this user, during impersonation time.
>
> The audit could be done in UserLoginHistory entity, storing
> impersonation period.
>
> Regards
>
> Gil
>
> Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
> > One idea that comes to my mind which might be useful is that we add a
> > flag in general.properties that by default enables this feature, and
> > we can then specify in the documentation that to secure OFBiz we need
> > to disable this feature so that it can be used in development but
> > disabled in production for people who prefer to be on the safe side. I
> > also like the suggestions from Pierre on perhaps having some kind of
> > audit trail, just like we have a log of party visits, we can have a
> > log of impersonation visits for example.
> >
> > Another idea, is perhaps to avoid completely persisting the session
> > into the system. In other words, once I impersonate some user, it's
> > done, I AM that user and I cannot go back. I have to log out and log
> > back in to access the system again as an admin. That might be a bit
> > more secure because we don't touch the session data.
> >
> > All food for thought, and I appreciate getting more feedback from the
> community.
> > On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits <[hidden email]>
> wrote:
> > >
> > > Impressive...
> > >
> > > This seems to be an in-OFBiz equivalent of an OS take-over tool like
> > > Microsoft's Remote Desktop. The business case (and use cases) are
> explained
> > > insufficiently in this thread or in the ticket ([1]) why incorporating
> this
> > > in the repo should be favourable over having the adopting business
> > > implement implement the OS take-over tool. What I feel missing here
> (and in
> > > the ticket) is the reference to the previous thread, which might
> explain
> > > the business case. I suggest to have a link to this thread also in the
> > > ticket
> > >
> > > Based on a cursory review of the patch, it is lacking serious aspects
> that
> > > will boost the confidence of any business adopter that this feature
> will
> > > not jeopardise their business operations. As it is now, I find the
> patch to
> > > basic to be committed to the repo and be included in any new release.
> > >
> > > As I see it it allows anybody with the IMPERSONATE_ADMIN permission
> take
> > > over any other ID and perform actions under that ID at anytime. I did
> not
> > > see any functionality (I am spitballing here) that:
> > >
> > >    1. would exclude any particular ID from being taken over (as a
> default
> > >    configuration)
> > >    2. would allow a user to disable the feature for their own account
> > >    (overriding the default permission of impersonation)
> > >    3. would allow a user to explicitly allow its ID to be taken over by
> > >    someone else, AND limit it for a specific amount of time
> (overriding aspect
> > >    #2 above).
> > >    4. would prohibit the impersonator to take over an ID when the user
> of
> > >    the ID is NOT logged in (which should be an additional default
> aspect).
> > >
> > > This feature seems 'impersonator' driven as the permission would not
> be on
> > > a case-by-case scenario, but rather on a semi-permanent permission
> > > assignment and by a user who has the - technical -  permission to set
> such
> > > a permission.
> > >
> > > What I furthermore feel lacking or underdeveloped is the audit and
> logging
> > > trail regarding this feature. Nowhere can be seen what actions (for the
> > > authentic ID) have been undertaken by the impersonator while the
> > > impersonation was in progress. Neither in logfiles, nor in screens in
> the
> > > Partymgr component (e.g. for the user to see).
> > >
> > > I advise the community to be very careful to commit this, without
> > > consideration of the above, into the repo.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/OFBIZ-10515
> > >
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > Apache Trafodion <https://trafodion.apache.org>, Vice President
> > > Apache Directory <https://directory.apache.org>, PMC Member
> > > Apache Incubator <https://incubator.apache.org>, committer
> > > Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
> > > Apache Steve <https://steve.apache.org>, committer
> > >
> > > On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
> > >
> > > > +1
> > > > ________________________________
> > > > 发件人: Rajesh Mallah <[hidden email]>
> > > > 发送时间: 2018年8月11日 11:10
> > > > 收件人: [hidden email]
> > > > 主题: Re: New Impersonate Feature : OFBIZ-10515
> > > >
> > > > This feature has valid use cases.
> > > > +1
> > > >
> > > > On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
> > > > [hidden email]> wrote:
> > > >
> > > > > Hello !
> > > > >
> > > > > I would like to introduce to you a new feature, i already talked
> about
> > > > some
> > > > > time ago (last year?). We needed it for one of our customer, that
> is
> > > > > using it for some time and is very happy with it (like we are).
> > > > >
> > > > > Indeed this impersonation feature comes to be very useful when we
> need
> > > > > to validate some behaviour or to assist a user in production
> without
> > > > > asking for its credential. It's became so easy to use that even in
> > > > > preproduction/integration environment we use it daily to
> impersonate
> > > > > specific configured userlogin without trying to remember the
> password...
> > > > >
> > > > > It's kinda basic, a new permission is created and can be granted
> to an
> > > > > authorized user, that will be offered a way to select a userlogin
> to
> > > > > impersonate.
> > > > >
> > > > > It's a common feature that can be found for example in Gitlab.
> > > > >
> > > > > If you wanna try it out it's available here :
> > > > > https://issues.apache.org/jira/browse/OFBIZ-10515
> > > > >
> > > > > Feedback are welcomed :), although i'll be partly offline next
> week.
> > > > >
> > > > > Looking forward reading you !
> > > > >
> > > > > Gil
> > > > >
> > > >
>

[Pierre Smits-3]

Consider this:
- having it enabled by default (as suggested by many)....
- enabling a user with higher privileges (suggested to be the OFBiz Admin)
to impersonate someone with lower privileges
- this user with higher privileges can now create/alter/etc... transactions
in accounting, ordermgr, warehousing, ecommence, etc. through OFBiz as the
impersonated user
- this user can prevent - through OFBiz - that others can see
UserLoginHistory.
- impersonation is in many countries - by law - a criminal offence
- this goes directly against GDPR

Caution is the Mother of the Porcelain Cabinet (as a saying in the
Netherlands goes). Especially when introducing features that have an impact
on security aspects.


Best regards,

Pierre Smits

Apache Trafodion <https://trafodion.apache.org>, Vice President
Apache Directory <https://directory.apache.org>, PMC Member
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Mon, Aug 20, 2018 at 12:04 PM, Taher Alkhateeb <
[hidden email]> wrote:

> I don't have a strong opinion on this, and I am open. My personal
> preference is pehaps to just 'login as' instead of impersonate with normal
> user login history. The reason for my preference is having the least amount
> of code written and least security worries. I find the impersonate feature
> also lovely and quite useful. So both directions are okay for me.
>
> On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne <
> [hidden email]>
> wrote:
>
> > Hello Taher,
> >
> > Thanks for your ideas, i think that had helped making it pop into
> > Nicolas answer to Pierre (that i just annoted).
> >
> > I hope the idea, that seem a mix of yours could be good enough, a
> property
> > that :
> > * by default allow any impersonation to be done in non-preproduction env,
> >  without logging out the user. (less security requirement)
> > * else, impersonation will logout the user impersonated, and restrict
> >  impersonation to one only for this user, during impersonation time.
> >
> > The audit could be done in UserLoginHistory entity, storing
> > impersonation period.
> >
> > Regards
> >
> > Gil
> >
> > Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
> > > One idea that comes to my mind which might be useful is that we add a
> > > flag in general.properties that by default enables this feature, and
> > > we can then specify in the documentation that to secure OFBiz we need
> > > to disable this feature so that it can be used in development but
> > > disabled in production for people who prefer to be on the safe side. I
> > > also like the suggestions from Pierre on perhaps having some kind of
> > > audit trail, just like we have a log of party visits, we can have a
> > > log of impersonation visits for example.
> > >
> > > Another idea, is perhaps to avoid completely persisting the session
> > > into the system. In other words, once I impersonate some user, it's
> > > done, I AM that user and I cannot go back. I have to log out and log
> > > back in to access the system again as an admin. That might be a bit
> > > more secure because we don't touch the session data.
> > >
> > > All food for thought, and I appreciate getting more feedback from the
> > community.
> > > On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits <[hidden email]>
> > wrote:
> > > >
> > > > Impressive...
> > > >
> > > > This seems to be an in-OFBiz equivalent of an OS take-over tool like
> > > > Microsoft's Remote Desktop. The business case (and use cases) are
> > explained
> > > > insufficiently in this thread or in the ticket ([1]) why
> incorporating
> > this
> > > > in the repo should be favourable over having the adopting business
> > > > implement implement the OS take-over tool. What I feel missing here
> > (and in
> > > > the ticket) is the reference to the previous thread, which might
> > explain
> > > > the business case. I suggest to have a link to this thread also in
> the
> > > > ticket
> > > >
> > > > Based on a cursory review of the patch, it is lacking serious aspects
> > that
> > > > will boost the confidence of any business adopter that this feature
> > will
> > > > not jeopardise their business operations. As it is now, I find the
> > patch to
> > > > basic to be committed to the repo and be included in any new release.
> > > >
> > > > As I see it it allows anybody with the IMPERSONATE_ADMIN permission
> > take
> > > > over any other ID and perform actions under that ID at anytime. I did
> > not
> > > > see any functionality (I am spitballing here) that:
> > > >
> > > >    1. would exclude any particular ID from being taken over (as a
> > default
> > > >    configuration)
> > > >    2. would allow a user to disable the feature for their own account
> > > >    (overriding the default permission of impersonation)
> > > >    3. would allow a user to explicitly allow its ID to be taken over
> by
> > > >    someone else, AND limit it for a specific amount of time
> > (overriding aspect
> > > >    #2 above).
> > > >    4. would prohibit the impersonator to take over an ID when the
> user
> > of
> > > >    the ID is NOT logged in (which should be an additional default
> > aspect).
> > > >
> > > > This feature seems 'impersonator' driven as the permission would not
> > be on
> > > > a case-by-case scenario, but rather on a semi-permanent permission
> > > > assignment and by a user who has the - technical -  permission to set
> > such
> > > > a permission.
> > > >
> > > > What I furthermore feel lacking or underdeveloped is the audit and
> > logging
> > > > trail regarding this feature. Nowhere can be seen what actions (for
> the
> > > > authentic ID) have been undertaken by the impersonator while the
> > > > impersonation was in progress. Neither in logfiles, nor in screens in
> > the
> > > > Partymgr component (e.g. for the user to see).
> > > >
> > > > I advise the community to be very careful to commit this, without
> > > > consideration of the above, into the repo.
> > > >
> > > >
> > > > [1] https://issues.apache.org/jira/browse/OFBIZ-10515
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > Apache Trafodion <https://trafodion.apache.org>, Vice President
> > > > Apache Directory <https://directory.apache.org>, PMC Member
> > > > Apache Incubator <https://incubator.apache.org>, committer
> > > > Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
> > > > Apache Steve <https://steve.apache.org>, committer
> > > >
> > > > On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
> > > >
> > > > > +1
> > > > > ________________________________
> > > > > 发件人: Rajesh Mallah <[hidden email]>
> > > > > 发送时间: 2018年8月11日 11:10
> > > > > 收件人: [hidden email]
> > > > > 主题: Re: New Impersonate Feature : OFBIZ-10515
> > > > >
> > > > > This feature has valid use cases.
> > > > > +1
> > > > >
> > > > > On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Hello !
> > > > > >
> > > > > > I would like to introduce to you a new feature, i already talked
> > about
> > > > > some
> > > > > > time ago (last year?). We needed it for one of our customer, that
> > is
> > > > > > using it for some time and is very happy with it (like we are).
> > > > > >
> > > > > > Indeed this impersonation feature comes to be very useful when we
> > need
> > > > > > to validate some behaviour or to assist a user in production
> > without
> > > > > > asking for its credential. It's became so easy to use that even
> in
> > > > > > preproduction/integration environment we use it daily to
> > impersonate
> > > > > > specific configured userlogin without trying to remember the
> > password...
> > > > > >
> > > > > > It's kinda basic, a new permission is created and can be granted
> > to an
> > > > > > authorized user, that will be offered a way to select a userlogin
> > to
> > > > > > impersonate.
> > > > > >
> > > > > > It's a common feature that can be found for example in Gitlab.
> > > > > >
> > > > > > If you wanna try it out it's available here :
> > > > > > https://issues.apache.org/jira/browse/OFBIZ-10515
> > > > > >
> > > > > > Feedback are welcomed :), although i'll be partly offline next
> > week.
> > > > > >
> > > > > > Looking forward reading you !
> > > > > >
> > > > > > Gil
> > > > > >
> > > > >
> >
>

[Jacques Le Roux]

Anyway an admin can do that and much other things by directly poking in the DB

So not really a concern for me

Jacques


Le 20/08/2018 à 14:04, Pierre Smits a écrit :

> Consider this:
> - having it enabled by default (as suggested by many)....
> - enabling a user with higher privileges (suggested to be the OFBiz Admin)
> to impersonate someone with lower privileges
> - this user with higher privileges can now create/alter/etc... transactions
> in accounting, ordermgr, warehousing, ecommence, etc. through OFBiz as the
> impersonated user
> - this user can prevent - through OFBiz - that others can see
> UserLoginHistory.
> - impersonation is in many countries - by law - a criminal offence
> - this goes directly against GDPR
>
> Caution is the Mother of the Porcelain Cabinet (as a saying in the
> Netherlands goes). Especially when introducing features that have an impact
> on security aspects.
>
>
> Best regards,
>
> Pierre Smits
>
> Apache Trafodion <https://trafodion.apache.org>, Vice President
> Apache Directory <https://directory.apache.org>, PMC Member
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
> On Mon, Aug 20, 2018 at 12:04 PM, Taher Alkhateeb <
> [hidden email]> wrote:
>
>> I don't have a strong opinion on this, and I am open. My personal
>> preference is pehaps to just 'login as' instead of impersonate with normal
>> user login history. The reason for my preference is having the least amount
>> of code written and least security worries. I find the impersonate feature
>> also lovely and quite useful. So both directions are okay for me.
>>
>> On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne <
>> [hidden email]>
>> wrote:
>>
>>> Hello Taher,
>>>
>>> Thanks for your ideas, i think that had helped making it pop into
>>> Nicolas answer to Pierre (that i just annoted).
>>>
>>> I hope the idea, that seem a mix of yours could be good enough, a
>> property
>>> that :
>>> * by default allow any impersonation to be done in non-preproduction env,
>>>   without logging out the user. (less security requirement)
>>> * else, impersonation will logout the user impersonated, and restrict
>>>   impersonation to one only for this user, during impersonation time.
>>>
>>> The audit could be done in UserLoginHistory entity, storing
>>> impersonation period.
>>>
>>> Regards
>>>
>>> Gil
>>>
>>> Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
>>>> One idea that comes to my mind which might be useful is that we add a
>>>> flag in general.properties that by default enables this feature, and
>>>> we can then specify in the documentation that to secure OFBiz we need
>>>> to disable this feature so that it can be used in development but
>>>> disabled in production for people who prefer to be on the safe side. I
>>>> also like the suggestions from Pierre on perhaps having some kind of
>>>> audit trail, just like we have a log of party visits, we can have a
>>>> log of impersonation visits for example.
>>>>
>>>> Another idea, is perhaps to avoid completely persisting the session
>>>> into the system. In other words, once I impersonate some user, it's
>>>> done, I AM that user and I cannot go back. I have to log out and log
>>>> back in to access the system again as an admin. That might be a bit
>>>> more secure because we don't touch the session data.
>>>>
>>>> All food for thought, and I appreciate getting more feedback from the
>>> community.
>>>> On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits <[hidden email]>
>>> wrote:
>>>>> Impressive...
>>>>>
>>>>> This seems to be an in-OFBiz equivalent of an OS take-over tool like
>>>>> Microsoft's Remote Desktop. The business case (and use cases) are
>>> explained
>>>>> insufficiently in this thread or in the ticket ([1]) why
>> incorporating
>>> this
>>>>> in the repo should be favourable over having the adopting business
>>>>> implement implement the OS take-over tool. What I feel missing here
>>> (and in
>>>>> the ticket) is the reference to the previous thread, which might
>>> explain
>>>>> the business case. I suggest to have a link to this thread also in
>> the
>>>>> ticket
>>>>>
>>>>> Based on a cursory review of the patch, it is lacking serious aspects
>>> that
>>>>> will boost the confidence of any business adopter that this feature
>>> will
>>>>> not jeopardise their business operations. As it is now, I find the
>>> patch to
>>>>> basic to be committed to the repo and be included in any new release.
>>>>>
>>>>> As I see it it allows anybody with the IMPERSONATE_ADMIN permission
>>> take
>>>>> over any other ID and perform actions under that ID at anytime. I did
>>> not
>>>>> see any functionality (I am spitballing here) that:
>>>>>
>>>>>     1. would exclude any particular ID from being taken over (as a
>>> default
>>>>>     configuration)
>>>>>     2. would allow a user to disable the feature for their own account
>>>>>     (overriding the default permission of impersonation)
>>>>>     3. would allow a user to explicitly allow its ID to be taken over
>> by
>>>>>     someone else, AND limit it for a specific amount of time
>>> (overriding aspect
>>>>>     #2 above).
>>>>>     4. would prohibit the impersonator to take over an ID when the
>> user
>>> of
>>>>>     the ID is NOT logged in (which should be an additional default
>>> aspect).
>>>>> This feature seems 'impersonator' driven as the permission would not
>>> be on
>>>>> a case-by-case scenario, but rather on a semi-permanent permission
>>>>> assignment and by a user who has the - technical -  permission to set
>>> such
>>>>> a permission.
>>>>>
>>>>> What I furthermore feel lacking or underdeveloped is the audit and
>>> logging
>>>>> trail regarding this feature. Nowhere can be seen what actions (for
>> the
>>>>> authentic ID) have been undertaken by the impersonator while the
>>>>> impersonation was in progress. Neither in logfiles, nor in screens in
>>> the
>>>>> Partymgr component (e.g. for the user to see).
>>>>>
>>>>> I advise the community to be very careful to commit this, without
>>>>> consideration of the above, into the repo.
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/OFBIZ-10515
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> Apache Trafodion <https://trafodion.apache.org>, Vice President
>>>>> Apache Directory <https://directory.apache.org>, PMC Member
>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>> Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>
>>>>> On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
>>>>>
>>>>>> +1
>>>>>> ________________________________
>>>>>> 发件人: Rajesh Mallah <[hidden email]>
>>>>>> 发送时间: 2018年8月11日 11:10
>>>>>> 收件人: [hidden email]
>>>>>> 主题: Re: New Impersonate Feature : OFBIZ-10515
>>>>>>
>>>>>> This feature has valid use cases.
>>>>>> +1
>>>>>>
>>>>>> On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> Hello !
>>>>>>>
>>>>>>> I would like to introduce to you a new feature, i already talked
>>> about
>>>>>> some
>>>>>>> time ago (last year?). We needed it for one of our customer, that
>>> is
>>>>>>> using it for some time and is very happy with it (like we are).
>>>>>>>
>>>>>>> Indeed this impersonation feature comes to be very useful when we
>>> need
>>>>>>> to validate some behaviour or to assist a user in production
>>> without
>>>>>>> asking for its credential. It's became so easy to use that even
>> in
>>>>>>> preproduction/integration environment we use it daily to
>>> impersonate
>>>>>>> specific configured userlogin without trying to remember the
>>> password...
>>>>>>> It's kinda basic, a new permission is created and can be granted
>>> to an
>>>>>>> authorized user, that will be offered a way to select a userlogin
>>> to
>>>>>>> impersonate.
>>>>>>>
>>>>>>> It's a common feature that can be found for example in Gitlab.
>>>>>>>
>>>>>>> If you wanna try it out it's available here :
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-10515
>>>>>>>
>>>>>>> Feedback are welcomed :), although i'll be partly offline next
>>> week.
>>>>>>> Looking forward reading you !
>>>>>>>
>>>>>>> Gil
>>>>>>>

[Pierre Smits-3]

Are we confident that this will not lead to a CVE when it will appear in a
release?


Best regards,

Pierre Smits

Apache Trafodion <https://trafodion.apache.org>, Vice President
Apache Directory <https://directory.apache.org>, PMC Member
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Mon, Aug 20, 2018 at 4:00 PM, Jacques Le Roux <
[hidden email]> wrote:

> Anyway an admin can do that and much other things by directly poking in
> the DB
>
> So not really a concern for me
>
> Jacques
>
>
> Le 20/08/2018 à 14:04, Pierre Smits a écrit :
>
>> Consider this:
>> - having it enabled by default (as suggested by many)....
>> - enabling a user with higher privileges (suggested to be the OFBiz Admin)
>> to impersonate someone with lower privileges
>> - this user with higher privileges can now create/alter/etc...
>> transactions
>> in accounting, ordermgr, warehousing, ecommence, etc. through OFBiz as the
>> impersonated user
>> - this user can prevent - through OFBiz - that others can see
>> UserLoginHistory.
>> - impersonation is in many countries - by law - a criminal offence
>> - this goes directly against GDPR
>>
>> Caution is the Mother of the Porcelain Cabinet (as a saying in the
>> Netherlands goes). Especially when introducing features that have an
>> impact
>> on security aspects.
>>
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> Apache Trafodion <https://trafodion.apache.org>, Vice President
>> Apache Directory <https://directory.apache.org>, PMC Member
>> Apache Incubator <https://incubator.apache.org>, committer
>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>> privileges)
>> since 2008*
>>
>> Apache Steve <https://steve.apache.org>, committer
>>
>> On Mon, Aug 20, 2018 at 12:04 PM, Taher Alkhateeb <
>> [hidden email]> wrote:
>>
>> I don't have a strong opinion on this, and I am open. My personal
>>> preference is pehaps to just 'login as' instead of impersonate with
>>> normal
>>> user login history. The reason for my preference is having the least
>>> amount
>>> of code written and least security worries. I find the impersonate
>>> feature
>>> also lovely and quite useful. So both directions are okay for me.
>>>
>>> On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne <
>>> [hidden email]>
>>> wrote:
>>>
>>> Hello Taher,
>>>>
>>>> Thanks for your ideas, i think that had helped making it pop into
>>>> Nicolas answer to Pierre (that i just annoted).
>>>>
>>>> I hope the idea, that seem a mix of yours could be good enough, a
>>>>
>>> property
>>>
>>>> that :
>>>> * by default allow any impersonation to be done in non-preproduction
>>>> env,
>>>>   without logging out the user. (less security requirement)
>>>> * else, impersonation will logout the user impersonated, and restrict
>>>>   impersonation to one only for this user, during impersonation time.
>>>>
>>>> The audit could be done in UserLoginHistory entity, storing
>>>> impersonation period.
>>>>
>>>> Regards
>>>>
>>>> Gil
>>>>
>>>> Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
>>>>
>>>>> One idea that comes to my mind which might be useful is that we add a
>>>>> flag in general.properties that by default enables this feature, and
>>>>> we can then specify in the documentation that to secure OFBiz we need
>>>>> to disable this feature so that it can be used in development but
>>>>> disabled in production for people who prefer to be on the safe side. I
>>>>> also like the suggestions from Pierre on perhaps having some kind of
>>>>> audit trail, just like we have a log of party visits, we can have a
>>>>> log of impersonation visits for example.
>>>>>
>>>>> Another idea, is perhaps to avoid completely persisting the session
>>>>> into the system. In other words, once I impersonate some user, it's
>>>>> done, I AM that user and I cannot go back. I have to log out and log
>>>>> back in to access the system again as an admin. That might be a bit
>>>>> more secure because we don't touch the session data.
>>>>>
>>>>> All food for thought, and I appreciate getting more feedback from the
>>>>>
>>>> community.
>>>>
>>>>> On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits <[hidden email]>
>>>>>
>>>> wrote:
>>>>
>>>>> Impressive...
>>>>>>
>>>>>> This seems to be an in-OFBiz equivalent of an OS take-over tool like
>>>>>> Microsoft's Remote Desktop. The business case (and use cases) are
>>>>>>
>>>>> explained
>>>>
>>>>> insufficiently in this thread or in the ticket ([1]) why
>>>>>>
>>>>> incorporating
>>>
>>>> this
>>>>
>>>>> in the repo should be favourable over having the adopting business
>>>>>> implement implement the OS take-over tool. What I feel missing here
>>>>>>
>>>>> (and in
>>>>
>>>>> the ticket) is the reference to the previous thread, which might
>>>>>>
>>>>> explain
>>>>
>>>>> the business case. I suggest to have a link to this thread also in
>>>>>>
>>>>> the
>>>
>>>> ticket
>>>>>>
>>>>>> Based on a cursory review of the patch, it is lacking serious aspects
>>>>>>
>>>>> that
>>>>
>>>>> will boost the confidence of any business adopter that this feature
>>>>>>
>>>>> will
>>>>
>>>>> not jeopardise their business operations. As it is now, I find the
>>>>>>
>>>>> patch to
>>>>
>>>>> basic to be committed to the repo and be included in any new release.
>>>>>>
>>>>>> As I see it it allows anybody with the IMPERSONATE_ADMIN permission
>>>>>>
>>>>> take
>>>>
>>>>> over any other ID and perform actions under that ID at anytime. I did
>>>>>>
>>>>> not
>>>>
>>>>> see any functionality (I am spitballing here) that:
>>>>>>
>>>>>>     1. would exclude any particular ID from being taken over (as a
>>>>>>
>>>>> default
>>>>
>>>>>     configuration)
>>>>>>     2. would allow a user to disable the feature for their own account
>>>>>>     (overriding the default permission of impersonation)
>>>>>>     3. would allow a user to explicitly allow its ID to be taken over
>>>>>>
>>>>> by
>>>
>>>>     someone else, AND limit it for a specific amount of time
>>>>>>
>>>>> (overriding aspect
>>>>
>>>>>     #2 above).
>>>>>>     4. would prohibit the impersonator to take over an ID when the
>>>>>>
>>>>> user
>>>
>>>> of
>>>>
>>>>>     the ID is NOT logged in (which should be an additional default
>>>>>>
>>>>> aspect).
>>>>
>>>>> This feature seems 'impersonator' driven as the permission would not
>>>>>>
>>>>> be on
>>>>
>>>>> a case-by-case scenario, but rather on a semi-permanent permission
>>>>>> assignment and by a user who has the - technical -  permission to set
>>>>>>
>>>>> such
>>>>
>>>>> a permission.
>>>>>>
>>>>>> What I furthermore feel lacking or underdeveloped is the audit and
>>>>>>
>>>>> logging
>>>>
>>>>> trail regarding this feature. Nowhere can be seen what actions (for
>>>>>>
>>>>> the
>>>
>>>> authentic ID) have been undertaken by the impersonator while the
>>>>>> impersonation was in progress. Neither in logfiles, nor in screens in
>>>>>>
>>>>> the
>>>>
>>>>> Partymgr component (e.g. for the user to see).
>>>>>>
>>>>>> I advise the community to be very careful to commit this, without
>>>>>> consideration of the above, into the repo.
>>>>>>
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/OFBIZ-10515
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> Apache Trafodion <https://trafodion.apache.org>, Vice President
>>>>>> Apache Directory <https://directory.apache.org>, PMC Member
>>>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>>>> Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
>>>>>> Apache Steve <https://steve.apache.org>, committer
>>>>>>
>>>>>> On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
>>>>>>
>>>>>> +1
>>>>>>> ________________________________
>>>>>>> 发件人: Rajesh Mallah <[hidden email]>
>>>>>>> 发送时间: 2018年8月11日 11:10
>>>>>>> 收件人: [hidden email]
>>>>>>> 主题: Re: New Impersonate Feature : OFBIZ-10515
>>>>>>>
>>>>>>> This feature has valid use cases.
>>>>>>> +1
>>>>>>>
>>>>>>> On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
>>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> Hello !
>>>>>>>>
>>>>>>>> I would like to introduce to you a new feature, i already talked
>>>>>>>>
>>>>>>> about
>>>>
>>>>> some
>>>>>>>
>>>>>>>> time ago (last year?). We needed it for one of our customer, that
>>>>>>>>
>>>>>>> is
>>>>
>>>>> using it for some time and is very happy with it (like we are).
>>>>>>>>
>>>>>>>> Indeed this impersonation feature comes to be very useful when we
>>>>>>>>
>>>>>>> need
>>>>
>>>>> to validate some behaviour or to assist a user in production
>>>>>>>>
>>>>>>> without
>>>>
>>>>> asking for its credential. It's became so easy to use that even
>>>>>>>>
>>>>>>> in
>>>
>>>> preproduction/integration environment we use it daily to
>>>>>>>>
>>>>>>> impersonate
>>>>
>>>>> specific configured userlogin without trying to remember the
>>>>>>>>
>>>>>>> password...
>>>>
>>>>> It's kinda basic, a new permission is created and can be granted
>>>>>>>>
>>>>>>> to an
>>>>
>>>>> authorized user, that will be offered a way to select a userlogin
>>>>>>>>
>>>>>>> to
>>>>
>>>>> impersonate.
>>>>>>>>
>>>>>>>> It's a common feature that can be found for example in Gitlab.
>>>>>>>>
>>>>>>>> If you wanna try it out it's available here :
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-10515
>>>>>>>>
>>>>>>>> Feedback are welcomed :), although i'll be partly offline next
>>>>>>>>
>>>>>>> week.
>>>>
>>>>> Looking forward reading you !
>>>>>>>>
>>>>>>>> Gil
>>>>>>>>
>>>>>>>>
>

[Gil Portenseigne]

Hello all,

A last patch is available for testing with the given improvement :
* add a security property that disable the feature by default
* add a security property that enable the production mode (impersonated
user is informed about the impersonation and cannot act during the process)
* add a control that prevent ADMIN impersonation
* add a control that prevent impersonation of a more privilege user
* add some documentation

Lastly for the criticity of depersonation (coming back to admin user), i
added a verification of the existence of an impersonation process. That
would ensure that this method could not be abused (the impersonation
process can only be set through a impersonation itself, or simulated with
access to database, so pretty reliable)

Any feedback are welcome :)

Gil

Le samedi 08 sept. 2018 à 11:32:17 (+0200), Pierre Smits a écrit :

> Are we confident that this will not lead to a CVE when it will appear in a
> release?
>
>
> Best regards,
>
> Pierre Smits
>
> Apache Trafodion <https://trafodion.apache.org>, Vice President
> Apache Directory <https://directory.apache.org>, PMC Member
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
> On Mon, Aug 20, 2018 at 4:00 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Anyway an admin can do that and much other things by directly poking in
> > the DB
> >
> > So not really a concern for me
> >
> > Jacques
> >
> >
> > Le 20/08/2018 à 14:04, Pierre Smits a écrit :
> >
> >> Consider this:
> >> - having it enabled by default (as suggested by many)....
> >> - enabling a user with higher privileges (suggested to be the OFBiz Admin)
> >> to impersonate someone with lower privileges
> >> - this user with higher privileges can now create/alter/etc...
> >> transactions
> >> in accounting, ordermgr, warehousing, ecommence, etc. through OFBiz as the
> >> impersonated user
> >> - this user can prevent - through OFBiz - that others can see
> >> UserLoginHistory.
> >> - impersonation is in many countries - by law - a criminal offence
> >> - this goes directly against GDPR
> >>
> >> Caution is the Mother of the Porcelain Cabinet (as a saying in the
> >> Netherlands goes). Especially when introducing features that have an
> >> impact
> >> on security aspects.
> >>
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> Apache Trafodion <https://trafodion.apache.org>, Vice President
> >> Apache Directory <https://directory.apache.org>, PMC Member
> >> Apache Incubator <https://incubator.apache.org>, committer
> >> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> >> privileges)
> >> since 2008*
> >>
> >> Apache Steve <https://steve.apache.org>, committer
> >>
> >> On Mon, Aug 20, 2018 at 12:04 PM, Taher Alkhateeb <
> >> [hidden email]> wrote:
> >>
> >> I don't have a strong opinion on this, and I am open. My personal
> >>> preference is pehaps to just 'login as' instead of impersonate with
> >>> normal
> >>> user login history. The reason for my preference is having the least
> >>> amount
> >>> of code written and least security worries. I find the impersonate
> >>> feature
> >>> also lovely and quite useful. So both directions are okay for me.
> >>>
> >>> On Mon, Aug 20, 2018, 12:07 PM Gil Portenseigne <
> >>> [hidden email]>
> >>> wrote:
> >>>
> >>> Hello Taher,
> >>>>
> >>>> Thanks for your ideas, i think that had helped making it pop into
> >>>> Nicolas answer to Pierre (that i just annoted).
> >>>>
> >>>> I hope the idea, that seem a mix of yours could be good enough, a
> >>>>
> >>> property
> >>>
> >>>> that :
> >>>> * by default allow any impersonation to be done in non-preproduction
> >>>> env,
> >>>>   without logging out the user. (less security requirement)
> >>>> * else, impersonation will logout the user impersonated, and restrict
> >>>>   impersonation to one only for this user, during impersonation time.
> >>>>
> >>>> The audit could be done in UserLoginHistory entity, storing
> >>>> impersonation period.
> >>>>
> >>>> Regards
> >>>>
> >>>> Gil
> >>>>
> >>>> Le mardi 14 août 2018 à 09:37:06 (+0300), Taher Alkhateeb a écrit :
> >>>>
> >>>>> One idea that comes to my mind which might be useful is that we add a
> >>>>> flag in general.properties that by default enables this feature, and
> >>>>> we can then specify in the documentation that to secure OFBiz we need
> >>>>> to disable this feature so that it can be used in development but
> >>>>> disabled in production for people who prefer to be on the safe side. I
> >>>>> also like the suggestions from Pierre on perhaps having some kind of
> >>>>> audit trail, just like we have a log of party visits, we can have a
> >>>>> log of impersonation visits for example.
> >>>>>
> >>>>> Another idea, is perhaps to avoid completely persisting the session
> >>>>> into the system. In other words, once I impersonate some user, it's
> >>>>> done, I AM that user and I cannot go back. I have to log out and log
> >>>>> back in to access the system again as an admin. That might be a bit
> >>>>> more secure because we don't touch the session data.
> >>>>>
> >>>>> All food for thought, and I appreciate getting more feedback from the
> >>>>>
> >>>> community.
> >>>>
> >>>>> On Mon, Aug 13, 2018 at 11:09 AM Pierre Smits <[hidden email]>
> >>>>>
> >>>> wrote:
> >>>>
> >>>>> Impressive...
> >>>>>>
> >>>>>> This seems to be an in-OFBiz equivalent of an OS take-over tool like
> >>>>>> Microsoft's Remote Desktop. The business case (and use cases) are
> >>>>>>
> >>>>> explained
> >>>>
> >>>>> insufficiently in this thread or in the ticket ([1]) why
> >>>>>>
> >>>>> incorporating
> >>>
> >>>> this
> >>>>
> >>>>> in the repo should be favourable over having the adopting business
> >>>>>> implement implement the OS take-over tool. What I feel missing here
> >>>>>>
> >>>>> (and in
> >>>>
> >>>>> the ticket) is the reference to the previous thread, which might
> >>>>>>
> >>>>> explain
> >>>>
> >>>>> the business case. I suggest to have a link to this thread also in
> >>>>>>
> >>>>> the
> >>>
> >>>> ticket
> >>>>>>
> >>>>>> Based on a cursory review of the patch, it is lacking serious aspects
> >>>>>>
> >>>>> that
> >>>>
> >>>>> will boost the confidence of any business adopter that this feature
> >>>>>>
> >>>>> will
> >>>>
> >>>>> not jeopardise their business operations. As it is now, I find the
> >>>>>>
> >>>>> patch to
> >>>>
> >>>>> basic to be committed to the repo and be included in any new release.
> >>>>>>
> >>>>>> As I see it it allows anybody with the IMPERSONATE_ADMIN permission
> >>>>>>
> >>>>> take
> >>>>
> >>>>> over any other ID and perform actions under that ID at anytime. I did
> >>>>>>
> >>>>> not
> >>>>
> >>>>> see any functionality (I am spitballing here) that:
> >>>>>>
> >>>>>>     1. would exclude any particular ID from being taken over (as a
> >>>>>>
> >>>>> default
> >>>>
> >>>>>     configuration)
> >>>>>>     2. would allow a user to disable the feature for their own account
> >>>>>>     (overriding the default permission of impersonation)
> >>>>>>     3. would allow a user to explicitly allow its ID to be taken over
> >>>>>>
> >>>>> by
> >>>
> >>>>     someone else, AND limit it for a specific amount of time
> >>>>>>
> >>>>> (overriding aspect
> >>>>
> >>>>>     #2 above).
> >>>>>>     4. would prohibit the impersonator to take over an ID when the
> >>>>>>
> >>>>> user
> >>>
> >>>> of
> >>>>
> >>>>>     the ID is NOT logged in (which should be an additional default
> >>>>>>
> >>>>> aspect).
> >>>>
> >>>>> This feature seems 'impersonator' driven as the permission would not
> >>>>>>
> >>>>> be on
> >>>>
> >>>>> a case-by-case scenario, but rather on a semi-permanent permission
> >>>>>> assignment and by a user who has the - technical -  permission to set
> >>>>>>
> >>>>> such
> >>>>
> >>>>> a permission.
> >>>>>>
> >>>>>> What I furthermore feel lacking or underdeveloped is the audit and
> >>>>>>
> >>>>> logging
> >>>>
> >>>>> trail regarding this feature. Nowhere can be seen what actions (for
> >>>>>>
> >>>>> the
> >>>
> >>>> authentic ID) have been undertaken by the impersonator while the
> >>>>>> impersonation was in progress. Neither in logfiles, nor in screens in
> >>>>>>
> >>>>> the
> >>>>
> >>>>> Partymgr component (e.g. for the user to see).
> >>>>>>
> >>>>>> I advise the community to be very careful to commit this, without
> >>>>>> consideration of the above, into the repo.
> >>>>>>
> >>>>>>
> >>>>>> [1] https://issues.apache.org/jira/browse/OFBIZ-10515
> >>>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Pierre Smits
> >>>>>>
> >>>>>> Apache Trafodion <https://trafodion.apache.org>, Vice President
> >>>>>> Apache Directory <https://directory.apache.org>, PMC Member
> >>>>>> Apache Incubator <https://incubator.apache.org>, committer
> >>>>>> Apache OFBiz <https://ofbiz.apache.org>, contributor since 2008
> >>>>>> Apache Steve <https://steve.apache.org>, committer
> >>>>>>
> >>>>>> On Mon, Aug 13, 2018 at 6:19 AM, Zhang Wei <[hidden email]> wrote:
> >>>>>>
> >>>>>> +1
> >>>>>>> ________________________________
> >>>>>>> 发件人: Rajesh Mallah <[hidden email]>
> >>>>>>> 发送时间: 2018年8月11日 11:10
> >>>>>>> 收件人: [hidden email]
> >>>>>>> 主题: Re: New Impersonate Feature : OFBIZ-10515
> >>>>>>>
> >>>>>>> This feature has valid use cases.
> >>>>>>> +1
> >>>>>>>
> >>>>>>> On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
> >>>>>>> [hidden email]> wrote:
> >>>>>>>
> >>>>>>> Hello !
> >>>>>>>>
> >>>>>>>> I would like to introduce to you a new feature, i already talked
> >>>>>>>>
> >>>>>>> about
> >>>>
> >>>>> some
> >>>>>>>
> >>>>>>>> time ago (last year?). We needed it for one of our customer, that
> >>>>>>>>
> >>>>>>> is
> >>>>
> >>>>> using it for some time and is very happy with it (like we are).
> >>>>>>>>
> >>>>>>>> Indeed this impersonation feature comes to be very useful when we
> >>>>>>>>
> >>>>>>> need
> >>>>
> >>>>> to validate some behaviour or to assist a user in production
> >>>>>>>>
> >>>>>>> without
> >>>>
> >>>>> asking for its credential. It's became so easy to use that even
> >>>>>>>>
> >>>>>>> in
> >>>
> >>>> preproduction/integration environment we use it daily to
> >>>>>>>>
> >>>>>>> impersonate
> >>>>
> >>>>> specific configured userlogin without trying to remember the
> >>>>>>>>
> >>>>>>> password...
> >>>>
> >>>>> It's kinda basic, a new permission is created and can be granted
> >>>>>>>>
> >>>>>>> to an
> >>>>
> >>>>> authorized user, that will be offered a way to select a userlogin
> >>>>>>>>
> >>>>>>> to
> >>>>
> >>>>> impersonate.
> >>>>>>>>
> >>>>>>>> It's a common feature that can be found for example in Gitlab.
> >>>>>>>>
> >>>>>>>> If you wanna try it out it's available here :
> >>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-10515
> >>>>>>>>
> >>>>>>>> Feedback are welcomed :), although i'll be partly offline next
> >>>>>>>>
> >>>>>>> week.
> >>>>
> >>>>> Looking forward reading you !
> >>>>>>>>
> >>>>>>>> Gil
> >>>>>>>>
> >>>>>>>>
> >

[Gabriel Oberreuter]

I think this feature will be really useful! We give support with other
systems, and the inpersonation functionality is handy in lots of cases.

Thanks! Will try it out in a couple of weeks.



--
Sent from: http://ofbiz.135035.n4.nabble.com/OFBiz-Dev-f165671.html

[Jacques Le Roux]

Hi Gabriel,

You message has been moderated and sent to the dev ML.

Please subscribe here http://ofbiz.apache.org/mailing-lists.html

Thanks

Jacques


Le 11/09/2018 à 15:05, Gabriel Oberreuter a écrit :

> I think this feature will be really useful! We give support with other
> systems, and the inpersonation functionality is handy in lots of cases.
>
> Thanks! Will try it out in a couple of weeks.
>
>
>
> --
> Sent from: http://ofbiz.135035.n4.nabble.com/OFBiz-Dev-f165671.html
>