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 <
slidingfilame...@gmail.com> 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 <
gil.portensei...@nereide.fr>
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 <pierresm...@apache.org>
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 <tzn...@msn.com> wrote:

+1
________________________________
发件人: Rajesh Mallah <mallah.raj...@gmail.com>
发送时间: 2018年8月11日 11:10
收件人: dev@ofbiz.apache.org
主题: Re: New Impersonate Feature : OFBIZ-10515

This feature has valid use cases.
+1

On Sat, Aug 11, 2018 at 1:30 AM, Gil Portenseigne <
gil.portensei...@nereide.fr> 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


Reply via email to