Is there any authentication system whose protocol always notifies the “target account” of impersonation?

Question

There are many forms of impersonation:

• Sudo in *nix
• Application impersonation (send as in Exchange)
• Any privileged user (helpdesk) logging in as a user so to not disclose the password
• RunAs Administrator in Windows

I'm looking for an authentication system, that itself, defines a sequence of steps to:

1. Log all valid impersonation attempts
2. Ensures the display those attempts to the account owner
3. The account owner either passively accepts, or marks them as suspicious.

In a sense this could be codified as an RFC, similar to how spam UCE is reported, or DMARC reporting.

My goal is to port this logic into a proprietary authentication system, keep the logging format the same, and if possible, track and update the disposition of each attempt.

I'm not trying to rework the wheel here, and think some prior work should exist.

Answer 1

The problem here is that all forms of impersonation are carried out for different reasons:

• sudo is normally used to allow a low privilege user to carry out tasks normally requiring higher level privileges
• Exchange impersonation can be used to allow any users of any privilege level to send messages as another user, but without allowing other functions of the account
• Helpdesk impersonation tends to allow high privilege users (IT staff) to take on the role of lower privilege users (everyone else) for specific purposes (in this case, "privilege" relates only to the system access - not the company hierarchy). However, it can also be used to allow for activity monitoring where there is a suspicion of wrong doing by an employee, for example.
• RunAs is essentially the same as sudo in this context

As a result, they all have differing requirements for logging and notification:

• sudo: should log the actual user account, and the activities performed
• Exchange: probably need to log the original user, but the activities are logged as part of normal usage, and since permission is normally granted by the legitimate user, may have an implicit "this action was performed by the main account holder" status, even if an impersonating user actually performed it. Consider a secretary sending a letter on behalf of a manager - the manager is usually considered to be the "sender", even if they didn't press "send" themselves.
• Helpdesk: the impersonation should be logged, but it can be difficult/impossible to log the specific activities performed. For example, they might just be showing a user how to find a dialog within a complex system, where the only method of logging would be noting where mouse clicks were, and potentially taking screenshots at those moments. If the employee is being investigated, notifying them may compromise the investigation.

Due to this problem, it's not really a topic which lends itself to standardization in an RFC - there would be so many exclusions and exceptions that it would be almost worthless, and virtually impossible to build an inter-operable system.

The steps you've outlined wouldn't work for some of the examples you have either:

• sudo - who would you notify? The root account? How does anyone access it? Through sudo, in a lot of modern systems!
• Exchange - one common use is for people to be able to respond to emails whilst the email recipient is on leave. If they had to get approval for each attempt, that use case falls down. It would be fine for other use cases, such as having one person prepare emails on behalf of another.
• Helpdesk - one common use case is to sort issues with logging into accounts. If a user can't log in, they can't accept the impersonation as valid until the issue is