Delegation vs Impersonation

Overview#

Delegation vs Impersonation has subtle but very important differences.

Typically, when we access a Website we do this in an effort to access Data of some type. Perhaps we need to access data about the news or we go to our Financial Institution to access our bank account. The "news" and our bank account are called Protected Resources. The news may not require Authentication to read the news, but we probably can not change the news without Authentication.

When we access the news, the website may not need to Authenticate the user (to read the news). (Even though the website may perform Identification using a cookie or some other method.)

When we access our Financial Institution we will and probably insist that Authentication be performed on the user accessing our bank account. The User in both of these cases is the Resource Owner.

Protected Resources are in many cases use a Data Store (like a database). Typically these Data Stores sit behind a Resource Server. In the case of the news, it could just be a Website with some sort of Content manager. In the bank account databases, these are Database Managers like an Oracle Server.

Use case Copy Password#

We have all probably used these sites or applications. These "Client Applications" allow us to access some Protected Resource. Like our bank account.

Some of these create a "Credential Vault" in which you store your passwords to other sites. Hopefully they protect this "Password Vault" well. Then they replay your password to the other sites to access the Protected Resources. (This is impersonation, not delegation). The Protected Resources thinks it is you accessing the resources and has no idea it is "Client Applications".

This use case also exposes the user's credentials to the "Client Application".

One of the biggest violators I know of is Quicken.

Some other Client Applications may just ask for our credentials to access the bank account in real time and do not use a Credential Vault.

Use Case Enterprise LDAP Authentication #

Many enterprises use a central LDAP for authentication services. Interestingly, this pattern is similar to the Password Vault Authentication Method. When using LDAP for authentication, a Client Application collects credentials directly from the user (in Plaintext) and then replays these credentials to the LDAP server to determine if they are valid. The Client Application must have access to the plaintext password of the user during the transaction; otherwise, it has no way to perform LDAP Authentication.

In a typical Enterprise LDAP Authentication setup, the user's credentials may be exposed to several applications and each of these applications are an exposure to an attacker.

Both of these Use cases#

Both of these Use cases, the Client Application is impersonating the Resource Owner (user), and the Protected Resource (our bank account) which has no way of distinguishing a call directly from the Resource Owner from a call being directed through a Client Application. Thus the Protected Resource has no method of Auditing to say otherwise.

Both of these approaches, are a Password Anti-Pattern of Sharing Your Password with the Client Application.

In a very real sense, both these Use cases is a form of Man-In-The-Middle attack on the user, although one that is hopefully benevolent in nature.

OAuth 2.0 Token Exchange[1]#

As specified in the OAuth 2.0 Token Exchange specification makes specific statements as to Delegation and Impersonation

When principal A impersonates principal B, A is given all the rights that B has within some defined rights context and A is indistinguishable from B in that context. Thus, when principal A impersonates principal B, then in so far as any entity receiving such a token is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on, but it is not a requirement. For all intents and purposes, when A is impersonating B, A is B.

Delegation and impersonation are not inclusive of all situations. When a principal is acting directly on its own behalf, for example, neither delegation nor impersonation are in play. They are, however, the more common semantics operating for token exchange and, as such, are given more direct treatment in OAuth 2.0 Token Exchange.

Delegation semantics are typically expressed in a token by including information about both the primary subject of the token as well as the actor to whom that subject has delegated some of its rights. Such a token is sometimes referred to as a composite token because it is composed of information about multiple subjects. Typically, in the request, the "subject_token" represents the identity of the party on behalf of whom the token is being requested while the "actor_token" represents the identity of the party to whom the access rights of the issued token are being delegated. A composite token issued by the authorization server will contain information about both parties. When and if a composite token is issued is at the discretion of the Authorization Server and applicable policy and configuration.

These subtle Delegation vs Impersonation become important within Accountable vs responsible discussions.

Microsoft Active Directory Impersonation vs Delegation[2]#

Impersonation flows the original caller's identity to back-end resources on the same computer. Delegation flows the original caller's Digital Identity to back-end resources on computers other than the Service Provider. LDAPWiki would generally call these Resource Servers.

For example, if a service is running within IIS without impersonation, the service will access resources using the ASP.NET account in IIS 5.0, or the Network Service account in IIS 6.0. With impersonation, if the client is connecting using the original caller's account, the service will access resources such as a SQL Server database on the same machine using the original caller's Digital Identity instead of the system ASP.NET account.

Delegation is similar except that the SQL Server database could be on a different machine that is remote to the service (Resource Server).

More Information#

There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!