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.

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.

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 ?

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.

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 ?

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