| Author |
Topic: Delegation Architecture vs. Trusted Subsystem |
|
SteveHB
member
offline  |
| |
| posts: |
113 |
| joined: |
05/31/2006 |
| from: |
Mountain View, CA |
|
|
 |
|
|
| Delegation Architecture vs. Trusted Subsystem |
In the Trusted Subsystem Model, all authentication and authorization for back-end resources occurs on the front-end server, e.g. the IIS Web application server. Typically, this model is used in conjunction with a role-based access control system that authorizes access to application-defined operations based on the user's role. After successfully authenticating and authorizing the user, the Web application server carries out the requested operation on behalf of the user by using a predefined service account, often the Web application process account.
In the Delegation Architecture Model, delegation enables the user’s credentials to be passed from one server to another. Delegation is the notion that a network resource or service can "flow" the identity of a user who originally authenticated to the service to some other service on the network.
|
|
|
|
|
|
|
SteveHB
member
offline  |
| |
| posts: |
113 |
| joined: |
05/31/2006 |
| from: |
Mountain View, CA |
|
|
|
|
|
| When delegation is the must? |
If the back-end server cares more about the original user than the front-end servers or middle tier servers, delegation is the only solution.
To be short, if you really want to know who put the crap on your desk then delegation is the only game in town.
|
|
|
|
|
|
|
SteveHB
member
offline |
| |
| posts: |
113 |
| joined: |
05/31/2006 |
| from: |
Mountain View, CA |
|
|
|
|
|
| What's difference between delegation and impersonation anyway? |
Impersonation enables an entity or subject to execute code and access resources in the context of an authenticated and authorized user, but only on the computer where subject is running. To access resources located on another computer on behalf of an impersonated user requires authentication delegation (or delegation for short). Delegation can be considered as a more powerful form of impersonation in that sense, as it enables impersonation across a network.
|
|
|
|
|
|
|
SteveHB
member
offline |
| |
| posts: |
113 |
| joined: |
05/31/2006 |
| from: |
Mountain View, CA |
|
|
|
|
|
| When delegation is possible? |
For delegation to work, an entity must be able to authenticate against the remote server using the credentials of the client you wish to delegate. However, there are numerous factors that determine if delegation can occur, such as Internet Information Services (IIS) authentication schemes, network authentication protocol, and the operating systems of the machines involved.
Misuse of delegation could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.
Authentication Schemes
On Windows 2000 or later version, the following authentication schemes impact delegation of impersonated clients as follows:
Anonymous -- NO
When using impersonation with an anonymous client, IIS impersonates the account specified by IIS for anonymous access. By default, this is a predifined service account named IUSR_<machinename> with a password controlled by IIS, which cannot be delegated.
Basic -- YES
When using Basic authentication, delegation is possible since IIS is able to get the client's username and password as well. Since the password is transmitted across the internet as a clear plain text. It is recommended the communication be made through a secure channel like SSL/TSL to prevent the client's credential from being exposed to the public.
Digest -- NO
Digest authentication does not permit delegation since IIS does not posses any credentials for the client with which to authenticate against the remote machine.
Integrated Windows Authentication -- YES/NO
When Internet Explorer attempts to access a protected resource, IIS sends two WWW-Authenticate headers to the browser, Negotiate and NTLM. The Negotiate header is only sent by IIS running on Windows 2000 or later. This header indicates that IIS supports the Negotiate protocol, which enables a negotiation to occur between Internet Explorer and IIS on whether to use Kerberos or NTLM authentication. IIS uses Kerberos if both the client (Internet Explorer 5.0 and later) and server (IIS 5.0 and later) are running Windows 2000 or later, and both are members of the same domain or trusted domains. Otherwise, the server defaults to using NTLM.
Since NTLM authenticates the user for IIS without providing the user's credentials to IIS, IIS cannot delegate that user's credentials to a remote machine.
When used in conjunction with Kerberos v5 authentication, IIS can delegate security credentials among computers running Windows 2000 or later that are trusted and configured for delegation.
Client Certificate Mapping -- YES/NO
Client Certificate Mapping supports delegation in some instances. That is, if you use IIS mapping (many-to-one) and the mapped account is identical (including password) to a local account on the remote machine, delegation is possible. In addition, delegation is possible if IIS maps the certificate to a domain account that has access to the remote machine. In both cases IIS stores credentials for the account in question.
However, if using Active Directory mapping (one-to-one), delegation is not possible. This is because Active Directory holds the certificate for each account, not IIS.
|
|
|
|
|
|
|
|
Email To Friend | 
Set Alert To This Topic
New Topic | 
Post Reply 
posted on: 06/02/2006 03:51:35 AM
Edit
Quote
Report
Profile
Reply