This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Delegation vs Impersonation
Delegation vs Impersonation

Version management

Difference between version and

At line 1 added 62 lines
!!! Overview
[{$pagename}] 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|DataStore] (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|Credential 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|Credential 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|impersonation] 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|Delegation] 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 [{$pagename}] become important within [Accountable vs responsible] discussions.
!! [Microsoft Active Directory] [Impersonation] vs [Delegation][2]
[Impersonation] flows the original caller's [identity|Digital 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]. [{$applicationname}] 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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-07|https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07|target='_blank'] - based on information obtained 2017-02-20
* [#2] - [What is the difference between impersonation and delegation?|https://msdn.microsoft.com/en-us/library/ff647248.aspx|target='_blank'] - based on data observed:2015-05-27
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop