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