If ASP.net is configured for Windows authentication, ASP.net relies on IIS to authenticate its clients with the configured authentication mode. IIS determines its authentication mode by examining the metabase settings for a particular application. After a user's identity is successfully authenticated, IIS passes the Windows token representing the authenticated user to the host asp.net asp.net worker process (w3wp.exe). If an application uses a virtual directory configured in IIS to support anonymous access, the token represents an anonymous Internet user account, otherwise the token represents an authenticated user.
IIS supports the following authentication modes:
Anonymous . If you do not need to authenticate clients (or use custom authentication mechanisms, such as forms authentication), you can configure IIS to allow anonymous access. In this event, IIS creates a Windows token to represent all anonymous users with the same anonymous (or guest) account. The default anonymous account is IUSR_machinename, where MachineName is the NetBIOS name of the computer specified during installation.
Basic . Basic authentication requires that users provide credentials in the form of a user name and password to prove their identity. Basic authentication is based on Internet standard RFC 2617, which is supported by all popular browsers. The user's credentials are routed from the browser to the WEB server in an unencrypted Base64 encoding format. To better protect these credentials, use Secure Sockets Layer (SSL) at the same time as Basic authentication. Because the WEB server contains unencrypted user credentials, the ASP.net application can impersonate callers and use their credentials to access network resources.
Integration of Windows. Integrated Windows authentication (formerly known as NTLM, also known as Windows NT Challenge/answer authentication, Windows NT Challenge/response) uses Kerberos v5 authentication or NTLM authentication, depending on the client and The configuration of the server. The server negotiates with the client to determine which protocol to use. Use Kerberos authentication if the following conditions are true:
asp.net Web applications are running under NetworkService accounts or custom domain accounts. If your application is running on a local account, such as the ASPNET account on Windows Server, NTLM authentication is used.
There is a service principal name (SPN) in Active Directory for the domain account that is used to run the services that the client uses to authenticate.
The client computer and the server computer need at least run Windows SQL Server and are in the same (that is, trusted) Windows domain.
note By default, Integrated Windows authentication is enabled for the Windows Server 2003 operating system. However, if Windows Server 2003 Service Pack 1 (SP1) is installed as part of the Windows Server 2003 operating system consolidation installation, Integrated Windows authentication is disabled by default. If you use SP1 to upgrade Windows Server 2003, the settings for Integrated Windows authentication are the same as those for Windows Server 2003.
You should use integrated Windows authentication instead of basic authentication because the former avoids the transmission of user credentials over the network. Because Kerberos v5 authentication supports mutual authentication, users can also authenticate the server that is being connected.
Integrated Windows authentication is best for an Intranet environment, where both the client computer and the WEB server computer are part of the same (that is, trusted) domain.
NTLM AuthenticationNTLM is the authentication protocol for Windows NT and Windows Server Workgroup environments. It is also used in a mixed Windows NT Active Directory domain environment that must be authenticated against a Windows NT system. Disables NTLM when Windows Server converts to native mode where there is no underlying Windows NT domain controller. Kerberos V5 then becomes the enterprise-class default authentication protocol.
NTLM authentication mechanism
Figure 1 shows the NTLM protocol.
windows authentication" alt="" src="http://files.jb51.net/file_images/article/201206/2012060620170811.gif">
The following is an overview of the challenge/response mechanism:
user requests Access . The user attempts to log on to the client by providing user credentials. Before logging in, the client computer caches the hash value of the password and discards the password. The client sends a request to the server that includes a user name and a plain text-formatted request.
The server sends a challenge message . The server generates a 16-byte random number called a challenge (that is, NONCE) and sends it to the client.
The client sends an answer message . The client uses a password hash value generated by the user's password to encrypt the challenge sent by the server. It sends the encrypted challenge back to the server in the form of an answer.
The server sends the challenge and answer to the domain controller . The server sends the user name, original challenge, and answer from the client computer to the domain controller.
The domain controller compares the challenge and answer to authenticate the user . The domain controller obtains the password hash value for the user, and then uses the hash value to encrypt the original challenge. Next, the domain controller compares the encrypted challenge to the response of the client computer. If a match is made, the domain controller sends the authenticated server acknowledgement for the user.
the server sends a response to the client . Assuming the credentials are valid, the server grants client access to the requested service or resource.
Kerberos AuthenticationKerberos authentication has the following advantages over NTLM authentication:
Mutual authentication . When a client authenticates a specific service on a particular server using the Kerberos V5 protocol, Kerberos provides the client with malicious code on the network that does not simulate the service's warranty.
Delegated Support . Servers that authenticate clients using Kerberos authentication can impersonate these clients and access network resources using the client's security context.
performance . Kerberos authentication provides improved performance that is superior to NTLM authentication.
Simplified Trust Management . Networks with multiple domains no longer require a complex set of explicit, point-to-point trust relationships.
Interoperability . The Kerberos protocol implemented by Microsoft is based on the standard tracking specification that is recommended to the Internet Engineering Task Force (IETF). Therefore, the implementation of the Protocol in Windows 2000 lays the groundwork for interoperability with other networks (where Kerberos version 5 is used for authentication).
Kerberos authentication mechanism
Figure 2 shows a simplified view of the Kerberos authentication protocol.
windows authentication" alt="" src="yun_qi_img/2012060620170812.gif">
After the client authenticates the network service, the Kerberos V5 protocol follows these steps:
Client from KDC Request TGT. The user attempted to log on to the client by providing user credentials. The Kerberos service on the client computer sends a Kerberos authentication service request to the Key Distribution Center (KDC). The request contains the user name, the service information obtained by the request ticket-granting ticket (ticket-granting ticket,tgt), and the timestamp that was encrypted using the user's long-term key (that is, the password).
note on Windows Server or the Windows Servers 2003 operating system, the domain controller acts as a KDC, and Active Directory hosts the security accounts database.
The authentication service sends encrypted TGT and session key . The KDC obtains a long-term key (that is, a password) for the user from Active Directory, and then decrypts the timestamp that was sent with the request. If the timestamp is valid, the user is the real user. The KDC Authentication Service creates a logon session key and encrypts the copy using the user's long-term key. The authentication service then creates a TGT that includes the user information and the logon session key. Finally, the authentication service encrypts the TGT with its own key and passes the encrypted session key and the encrypted TGT to the client.
Client from TGT Request server Access . The client decrypts the logon session key with its long-term key (that is, the password) and caches it locally. In addition, the client stores the encrypted TGT in its cache. When accessing a network service, the client sends a request to the KDC ticket-granting Service (ticket-granting SERVICE,TGS) that contains information, including the user name, the authenticator message encrypted with the user logon session key, the TGT, and the service that the user wants to access (and ) name.
TGS sends an encrypted session key and ticket . The TGS on the KDC decrypts the KDC using its own key and extracts the login session key. It decrypts the authenticator message (usually a timestamp) using the login session key. If the authenticator message is successfully decrypted, TGS extracts the user information from the TGT and creates a service session key for accessing the service using the user information. It encrypts a copy of the service session key using the user's logon session key, creates a service ticket with the service session key and user information, and then encrypts the service ticket using the service's long-term key (password). TGS then adds the encrypted service session key and service ticket to the client.
The client sends a service ticket . Sends a request to the server when the client accesses the service. The request contains a validator message (timestamp) that is encrypted using the service session key and the service ticket.
The server sends an encrypted timestamp for client authentication . The server decrypts the service ticket and extracts the service session key. By using the service session key, the server decrypts the authenticator message (the timestamp) and computes it. If the authenticator passes the test, the server encrypts the authenticator (timestamp) using the service session key, and then passes the authenticator back to the client. The client decrypts the timestamp, and if the timestamp is the same as the original timestamp, the service is true and the client continues to connect.
The principal name of the service
The Kerberos V5 authentication protocol uses the service's primary name (SPN) for the following reasons:
Supports mutual authentication.
Allows a client to request a ticket, which in turn allows the client to communicate with a specific service.
For example, if a client needs to obtain a ticket and authenticate a specific service (MyService) on a computer running on listening port 4766 (MyServer), the client uses the name constructed based on that information from the KDC Request a ticket, as follows:
myservice/myserver:4766
The SPN registered in Active Directory maintains a mapping between the name and the domain account that is running the requested service. By using this mechanism, it is difficult for a malicious user to simulate a service on the network. A malicious user must disable the actual service and remove the actual server from the network. A malicious user must then add a new computer with the same name to the network and expose duplicate services. Because the client uses the Kerberos V5 protocol with mutual authentication, the client will not be able to use the duplicate service unless it can provide the password for the domain account that configures the actual service to run.
Kerberos AuthenticationKerberos authentication has the following advantages over NTLM authentication:
Mutual authentication . When a client authenticates a specific service on a particular server using the Kerberos V5 protocol, Kerberos provides the client with malicious code on the network that does not simulate the service's warranty.
Delegated Support . Servers that authenticate clients using Kerberos authentication can impersonate these clients and access network resources using the client's security context.
performance . Kerberos authentication provides improved performance that is superior to NTLM authentication.
Simplified Trust Management . Networks with multiple domains no longer require a complex set of explicit, point-to-point trust relationships.
Interoperability . The Kerberos protocol implemented by Microsoft is based on the standard tracking specification that is recommended to the Internet Engineering Task Force (IETF). Therefore, the implementation of the Protocol in Windows 2000 lays the groundwork for interoperability with other networks (where Kerberos version 5 is used for authentication).
Kerberos authentication mechanism
Figure 2 shows a simplified view of the Kerberos authentication protocol.
After the client authenticates the network service, the Kerberos V5 protocol follows these steps:
Client from KDC Request TGT. The user attempted to log on to the client by providing user credentials. The Kerberos service on the client computer sends a Kerberos authentication service request to the Key Distribution Center (KDC). The request contains the user name, the service information obtained by the request ticket-granting ticket (ticket-granting ticket,tgt), and the timestamp that was encrypted using the user's long-term key (that is, the password).
note on Windows Server or the Windows Servers 2003 operating system, the domain controller acts as a KDC, and Active Directory hosts the security accounts database.
The authentication service sends encrypted TGT and session key . The KDC obtains a long-term key (that is, a password) for the user from Active Directory, and then decrypts the timestamp that was sent with the request. If the timestamp is valid, the user is the real user. The KDC Authentication Service creates a logon session key and encrypts the copy using the user's long-term key. The authentication service then creates a TGT that includes the user information and the logon session key. Finally, the authentication service encrypts the TGT with its own key and passes the encrypted session key and the encrypted TGT to the client.
Client from TGT Request server Access . The client decrypts the logon session key with its long-term key (that is, the password) and caches it locally. In addition, the client stores the encrypted TGT in its cache. When accessing a network service, the client sends a request to the KDC ticket-granting Service (ticket-granting SERVICE,TGS) that contains information, including the user name, the authenticator message encrypted with the user logon session key, the TGT, and the service that the user wants to access (and ) name.
TGS sends an encrypted session key and ticket . The TGS on the KDC decrypts the KDC using its own key and extracts the login session key. It decrypts the authenticator message (usually a timestamp) using the login session key. If the authenticator message is successfully decrypted, TGS extracts the user information from the TGT and creates a service session key for accessing the service using the user information. It encrypts a copy of the service session key using the user's logon session key, creates a service ticket with the service session key and user information, and then encrypts the service ticket using the service's long-term key (password). TGS then adds the encrypted service session key and service ticket to the client.
The client sends a service ticket . Sends a request to the server when the client accesses the service. The request contains a validator message (timestamp) that is encrypted using the service session key and the service ticket.
The server sends an encrypted timestamp for client authentication . The server decrypts the service ticket and extracts the service session key. By using the service session key, the server decrypts the authenticator message (the timestamp) and computes it. If the authenticator passes the test, the server encrypts the authenticator (timestamp) using the service session key, and then passes the authenticator back to the client. The client decrypts the timestamp, and if the timestamp is the same as the original timestamp, the service is true and the client continues to connect.
The principal name of the service
The Kerberos V5 authentication protocol uses the service's primary name (SPN) for the following reasons:
Supports mutual authentication.
Allows a client to request a ticket, which in turn allows the client to communicate with a specific service.
For example, if a client needs to obtain a ticket and authenticate a specific service (MyService) on a computer running on listening port 4766 (MyServer), the client uses the name constructed based on that information from the KDC Request a ticket, as follows:
myservice/myserver:4766
The SPN registered in Active Directory maintains a mapping between the name and the domain account that is running the requested service. By using this mechanism, it is difficult for a malicious user to simulate a service on the network. A malicious user must disable the actual service and remove the actual server from the network. A malicious user must then add a new computer with the same name to the network and expose duplicate services. Because the client uses the Kerberos V5 protocol with mutual authentication, the client will not be able to use the duplicate service unless it can provide the password for the domain account that configures the actual service to run.
asp.net authenticationIIS passes a token to asp.net that represents an authenticated user or an anonymous user account. The token is maintained in a iidentity object that is contained in the IPrincipal object, and theIPrincipal object is then appended to the current WEB request thread. You can access IPrincipal and iidentity objects through the HttpContext.User property. These objects and the property are set by the authentication module, which is implemented as an HTTP module and invoked as a standard part of the ASP.net pipeline, as shown in Figure 3.
The ASP.net piping model contains a HttpApplication object, multiple HTTP module objects, and an HTTP handler object and its associated factory object. The HttpRuntime object is used to process the beginning of the sequence. During the entire request lifecycle, theHttpContext object is used to pass detailed information about the request and the response.
For more information about the ASP.net request lifecycle, see "asp.net life Cycle", the URL is http://msdn2.microsoft.com/library/ms227435 (en-us,vs.80). aspx.
Authentication Module
ASP.net 2.0 defines a set of HTTP modules in the computer-level Web.config file. This includes a large number of authentication modules, as follows:
Only one authentication module is loaded, depending on which authentication mode is specified in the authentication element of the configuration file. The authentication module creates a IPrincipal object and stores it in the HttpContext.User property. This is critical because other authorization modules use the IPrincipal object to make authorization decisions.
When anonymous access is enabled in IIS and the authentication element's mode property is set to none , a special module adds the default anonymous principle to the httpcontext.user< The/c3> property. Therefore, after authentication,HttpContext.User is by no means a null reference (Nothing in Visual Basic).
WindowsAuthenticationModule
If the Web.config file contains the following elements, the WindowsAuthenticationModule class is activated.
<authentication mode= "Windows"/>The WindowsAuthenticationModule class is responsible for creating WindowsPrincipal and WindowsIdentity objects to represent authenticated users. and is responsible for attaching these objects to the current WEB request.
For Windows authentication, follow these steps:
WindowsAuthenticationModule creates a WindowsPrincipal object using a Windows access token that is passed from IIS to ASP.net. The token is wrapped in the workerrequest property of the HttpContext class. When the AuthenticateRequest event is raised,WindowsAuthenticationModule retrieves the token from the HttpContext class and creates WindowsPrincipal object. HttpContext.User is set with the WindowsPrincipal object, which represents the security context of all authenticated modules and ASP.net pages of authenticated users.
The WindowsAuthenticationModule class uses P/invoke to invoke the WIN32 function and obtain a list of the Windows groups to which the user belongs. These groups are used to populate the WindowsPrincipal role list.
The WindowsAuthenticationModule class stores the WindowsPrincipal object in the HttpContext.User property. The authorization module then uses it to authorize authenticated users.
Note: The Defaultauthenticationmodule class (also part of the asp.net pipe) sets the Thread.CurrentPrincipal property to the same value as the HttpContext.User property. It does this after the authenticaterequest event is processed.
Authorization module
After the WindowsAuthenticationModule class completes its processing, the authorization module is invoked if the request is not rejected. The authorization module is also defined in the httpmodules element in the computer-level Web.config file, as follows:
UrlAuthorizationModule
When the UrlAuthorizationModule class is invoked, it looks for the authorization element in the machine-level or application-specific Web.config file. If the element exists, the UrlAuthorizationModule class retrieves the IPrincipal object from the HttpContext.User property and then uses the specified verb (GET, POST, and so on) to determine whether the user is authorized to access the requested resource.
FileAuthorizationModule
Next, call the FileAuthorizationModule class. It checks whether the IIdentity object in the HttpContext.User.Identity property is an instance of the WindowsIdentity class. If the iidentity object is not an instance of the WindowsIdentity class, the FileAuthorizationModule class stops processing.
If an instance of the WindowsIdentity class exists, the FileAuthorizationModule class invokes the AccessCheck Win32 function (through p/ Invoke) to determine whether authenticated clients are authorized to access the requested file. If the file's security descriptor's discretionary access control List (DACL) contains at least one Read access control Entry (ACE), the request is allowed to continue. Otherwise, theFileAuthorizationModule class calls the Httpapplication.completerequest method and returns the status code 401 to the client.
Security context
The. NET Framework encapsulates Windows tokens and logon sessions using the following two interfaces:
System.Security.Principal.IPrincipal
System.Security.Principal.IIdentity(it is exposed as a property in the IPrincipal interface.) ）
HttpContext.User
In asp.net, use the WindowsPrincipal and WindowsIdentity classes to represent the security context for users who authenticate with Windows authentication. asp.net applications that use Windows authentication can access the WindowsPrincipal class through the HttpContext.User property.
To retrieve the security context for the Windows authenticated user that initiated the current request, use the following code:
Using System.Security.Principal; ...//Obtain the authenticated user ' s Identity windowsprincipal winprincipal = (WindowsPrincipal) HttpContext.Current.User;
WindowsIdentity.GetCurrent
The windowsidentity.getcurrent method can be used to obtain the identity of the security context of the currently running WIN32 thread. If you do not use impersonation, the thread inherits the security context of the process on IIS 6.0 (the NetworkService account by default).
This security context is used when accessing local resources. By using the security context of an authenticated initial user or using a fixed identity, you can use impersonation to override the security contexts.
To retrieve the security context in which the application is running, use the following code:
Using System.Security.Principal; ...//Obtain the authenticated user's identity. WindowsIdentity Winid = WindowsIdentity.GetCurrent (); WindowsPrincipal Winprincipal = new WindowsPrincipal (Winid);
Thread.CurrentPrincipal
Each thread in the ASP.net application exposes a CurrentPrincipal object that holds the security context of the authenticated initial user. This security context can be used for role-based authorization.
To retrieve the current principle of the thread, use the following code:
Using System.Security.Principal; ...//Obtain the authenticated user ' s identity windowsprincipal Winprincipal = (WindowsPrincipal) Thread.currentprincipa L ();
Table 1 shows the identification of the results obtained from various identity properties, which can be used from the ASP.net application when your application uses Windows authentication and IIS is configured to use Integrated Windows authentication.
Table 1: Thread-exposed CurrentPrincipal Object
Web.config settings |
Variable position |
Result identification |
|---|---|---|
<identity impersonate= "true"/> |
HttpContext |
DOMAIN\username |
<identity impersonate= "false"/> |
HttpContext |
DOMAIN\username |
<identity impersonate= "true"/> |
HttpContext |
User-supplied name |
<identity impersonate= "false"/> |
HttpContext |
User-supplied name |
Simulation
asp.net applications can use impersonation to perform operations that access resources using the security context of an authenticated client or a specific Windows account.
Initial User Impersonation
To simulate an initial (authenticated) user, use the following configuration in the Web.config file:
<authentication mode= "Windows"/> <identity impersonate= "true"/>
With this configuration, ASP.net always impersonates authenticated users, and all resource access is performed using the security context of the authenticated user. If anonymous access is enabled on the virtual directory of your application, impersonate the IUSR_machinename account.
To temporarily impersonate an authenticated caller, set the impersonate property of the identity element to false, and then use the following code:
Using System.Security.Principal; ...//Obtain the authenticated user's identity. WindowsIdentity Winid = (WindowsIdentity) HttpContext.Current.User.Identity; windowsimpersonationcontextCTX = null; try {//Start impersonating. CTX = Winid.impersonate ();//Now impersonating.//Access resources using the identity of T He authenticated user. }//Prevent exceptions from propagating. Catch {} finally {//Revert impersonation. if (CTX!= null) ctx. Undo (); }//back to running under the default ASP.net process identity.This code simulates the authenticated initial user. Maintains the identity of the initial user and the Windows token in the HttpContext.Current.User.Identity object.
Fixed identity Impersonation
If you need to simulate the same identity throughout the lifecycle of your application, you can specify credentials on the identity element in the Web.config file. The following example shows how to simulate a Windows account named "TestUser".
If you use this method, you should encrypt these credentials. Using ASP.net 2.0, you can use the ASP.net IIS Registration tool (Aspnet_regiis.exe). Using the ASP.net version 1.1, you can use the Aspnet_setreg.exe utility. For more information about this utility, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/ cpgrfaspnetiisregistrationtoolaspnet_regiisexe.asp.
To use a fixed identity for resource access in an ASP.net application, you can configure credentials by using the identity element on Windows Server or Windows 2003. If you are running Windows Server 2003, where IIS 6.0 is configured to run in worker process isolation mode (by default), you can avoid impersonation by configuring the ASP.net application to run in a custom application pool (run under a specific domain identity). You can then use the specified domain identity to access the resource without using impersonation.
Commissioned
Impersonation provides access only to local resources. A delegate is an extended impersonation feature that allows you to access network resources using an impersonation token.
If your application authenticates its users using Kerberos V5 authentication, you can use the Kerberos delegate to pass the user identity and access network resources at each layer of the application. If your application does not use Kerberos V5 authentication, you can use protocol transformation to switch to Kerberos and then use the delegate to pass the identity.
A constraint delegate in Windows Server 2003 requires Kerberos authentication. If your application cannot authenticate its callers using Kerberos authentication, you can switch to Kerberos authentication from an optional non-Windows authentication mode (such as form or certificate authentication) using the Protocol transformation. You can then use Kerberos with the constraint delegate to access downstream network resources.
Constrained and unconstrained delegates
The Kerberos delegate on Windows Server is not bound . A server with a delegate configured in Active Directory can access any network resource or any computer on the network while using the impersonated user security context. This poses a potential security threat, especially if the WEB server is under attack by a malicious user.
To address this security issue, Windows Server 2003 introduces a delegate for the constraint. This allows administrators to accurately specify services that can be accessed by another server or domain account when using the impersonated user security context.
Configuring delegates
To use the Kerberos delegate, you need the appropriate Active Directory configuration.
To grant the WEB server permission to delegate client credentials, configure Active Directory as follows:
If you run an application under the NetworkService account, the WEB server computer account must be marked as a trusted delegate in Active Directory.
If you run the application under a custom domain account, the user account must be marked as a trusted delegate in Active Directory.
If your application simulates a user account, make sure that the user account that the application impersonates is not marked as "sensitive account and cannot be delegated" in Active Directory.
For more information about protocol conversions and constraint delegates, see How to To:use Protocol Transition and constrained delegation in ASP.net 2.0.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
