HelpDesking

  
Hi everyone,

I was wondering if you had any suggestions for a specific common issue.

When one is helpdesking an application, which has features related to a specific user, the best way to understand what a user says is to see exactly what he sees.

A way to solve this is to provide a mechanism to login with the user username, without providing password.

The problem with this solution is that it is a major security failure, because you cannot ever be sure that your logging history really relates to a specific user or to someone impersonating him....

This is a recurrent situation, so i wonder what your solutions are.

Best Regards,

Diogo C S Cordeiro
Hi,

I'm a beginner, but i was wondering if "Embedded Change Technology " could be part of the solution...

Best regards,

MM
Hello Marcelino,

ECT is indeed great to visualize the error a customer gets, but the ability to reproduce it is very limited, and is more directed to IT...

What i'm talking about is an impersonation feature, without loosing the track of the user that is impersonating.


Best Regards,

Diogo C S Cordeiro
Hello Diogo,

What I understand from you're post is that when a customer get's a error, he tell the helpdesk what te problem is and the helpdesk can login on the helpdesk pc in the system under the account of the customer and see what the problem is?

First I ask if thats really the good way to use. A problem can occurd by very different reasons (think about browser (version)).


The solution I'm thinking about works with the permission area's of outsystems. If you haven't used this maybe read below for suggestions.

Copy the customers usermaster in a usermaster of (for example) 'helpdesk'. Helpdesk has it's own password witch attribute doesn't need to be copied. This way you're helpdesk password always stays the same. You also copy the usermaster role of the customer in the usermaster role of you're helpdesk user. On this way the user helpdesk has the settings of the customer but have it's own password. You can login and look for the problem.

To execute the action for the copy I was thinking about a action hidden somewhere under a icon/link/whatever in the header or footer that the custom have to press when a error occured (helpdesk person can tell the customer where to press) or just add a menu item?

Need to solve more problems on the same time? I was thinking about more helpdesk users (helpdesk1, helpdesk 2 and so on) with are filled by a counter or switch. By the feedback message of the systems the customer can tell the helpdesk user witch message it got (message example: 'helpdesk 1 needed', 'helpdesk2 needed' or '1', '2' or just 'helpdesk1' and so on) with helpdesk-useraccount is needed by the helpdesk user.

Hope this is usefull for you?

Kind Regards,
Evert

Hi Diogo,

 

Impersonation has been implemented within customized solutions of Enterprise Manager. You can have, say, an Impersonate User link on the User Account page that transparently logs in to the application as that chosen user.

 

Nevertheless, since this may also be considered a dangerous security breach it only depends on your application requirements and should always be validated beforehand.

 

Regards,

Pedro

Thank you for the replies Pedro and Evert...

Well, i have had previously implemented mechanism for logging in without needing to know a specific password (and eventually only make it available for certain users). The issue here is if that super-user interacts with the system, the user that will be logged is the one that is being impersonated...

Evert, what did you mean with "Copy the customers usermaster in a usermaster of (for example) 'helpdesk'." ?

I wonder if I could just fill in a session variable indicating the username of the "impersonator", and then when i wished to log, i would just check that session variable.... Do session variables survive logout/login mechanisms ?

Is this ok, for security matters?

Best Regards,

Diogo C S Cordeiro


Hi Diogo,

What I mean with "Copy the customers usermaster in a usermaster of (for example) 'helpdesk'" is the following:

A User is (common) stored in the entity of User_Master (reference from enterprisemanager). In this table you can find his personal data (name, email, phone) but also his password. This User_Master also has a role assignd to it with is connected (trough the enterprise manager) to a permission area. So the customer has a account with data is hold in the entity of user_master.

If you create a account for the helpdesk in the enterprise manager, this will stored in the user_master table. You can assign a helpdesk password to it. So if you want to log in to the systems 'like' the customer, you have to copy the customers data (with is stored in the user_master table) to the helpdesk account. Now you have an account with is exactly the same as the customer, but you login name and password are different. Now you're helpdesk can login with this account and see what is happening.

Hope now you understand what I mean?

Kind Regards,
Evert
Hello Evert,

Thanks for your detailed explanation. I think that now i understand what you mean.

That could work if there wasn't any data connected to a specific user, and if you remove the unique index on the username attribute.
The question urges when there is screen data associated with a user's ID. So, unless one duplicates all info connected to that user ID, which i don't see viable, the only solution I see is to actually login as the user...

I just wonder about session variables...Is it ok, for security matters, to fill in some session variable with the helpdesk user Id, while the main user is the one i want to impersonate ?

Best Regards,

Diogo C S Cordeiro


Hi diogo,

Didn't thought about that option, but you're right about it.

I'm not a big fan of using session variables because of the serurity matters (if can avoid!) but if it's only is the UserId and not the username/password I'll think you could use it.


Thougt about another option:

Customer must press a buton (placed somewhere in the system) with execute a ation that saves the password of the user (if not already done then encrypted) in the database and then fill in a helpdesk password. Now the helpdesk user can login with the username of the customer but with the (predefined) password of the helpdesk. This way the helpdesk user can find the problem that occurd at the customer.

After using it the helpdesk user press a button that set back the original password of the customer (or you could say that you do it with a timer (so no client scripting will be used), but you never now how much time it's gonne take).

Hope this will be a woking solution?

Kind Regards,
Evert