Building Secure ASP.NET Applications phần 8 pptx

Building Secure ASP.NET Applications382 4. Construct GenericPrincipal and FormsIdentity Objects This procedure implements an application authentication event handler and constructs GenericPrincipal and FormsIdentity objects based on information contained within the authentication ticket.  To construct GenericPrincipal and FormsIdentity objects 1. From Solution Explorer, open global.asax. 2. Switch to code view and add the following using statements to the top of the file: using System.Web.Security; using System.Security.Principal; 3. Locate the Application_AuthenticateRequest event handler and add the follow- ing code to obtain the forms authentication cookie from the cookie collection passed with the request. // Extract the forms authentication cookie string cookieName = FormsAuthentication.FormsCookieName; HttpCookie authCookie = Context.Request.Cookies[cookieName]; if(null == authCookie) { // There is no authentication cookie. return; } 4. Add the following code to extract and decrypt the authentication ticket from the forms authentication cookie. FormsAuthenticationTicket authTicket = null; try { authTicket = FormsAuthentication.Decrypt(authCookie.Value); } catch(Exception ex) { // Log exception details (omitted for simplicity) return; } if (null == authTicket) { // Cookie failed to decrypt. return; } How To: Create GenericPrincipal Objects with Forms Authentication 383 5. Add the following code to parse out the pipe separate list of role names attached to the ticket when the user was originally authenticated. // When the ticket was created, the UserData property was assigned a // pipe delimited string of role names. string[] roles = authTicket.UserData.Split(new char[]{'|'}); 6. Add the following code to create a FormsIdentity object with the user name obtained from the ticket name and a GenericPrincipal object that contains this identity together with the user’s role list. // Create an Identity object FormsIdentity id = new FormsIdentity( authTicket ); // This principal will flow throughout the request. GenericPrincipal principal = new GenericPrincipal(id, roles); // Attach the new principal object to the current HttpContext object Context.User = principal; 5. Test the Application This procedure adds code to the default.aspx page to display information from the GenericPrincipal object attached to the current HttpContext object, to confirm that the object has been correctly constructed and assigned to the current Web request. You will then build and test the application.  To test the application 1. In Solution Explorer, double-click default.aspx. 2. Double-click the default.aspx Web form to display the page load event handler. 3. Scroll to the top of the file and add the following using statement beneath the existing using statements. using System.Security.Principal; 4. Return to the page load event handler and add the following code to display the identity name attached to the GenericPrincipal associated with the current Web request. IPrincipal p = HttpContext.Current.User; Response.Write( "Authenticated Identity is: " + p.Identity.Name ); Response.Write( "<p>" ); Building Secure ASP.NET Applications384 5. Add the following code to test role membership for the current authenticated identity. if ( p.IsInRole("Senior Manager") ) Response.Write( "User is in Senior Manager role<p>" ); else Response.Write( "User is not in Senior Manager role<p>" ); if ( p.IsInRole("Manager") ) Response.Write( "User is in Manager role<p>" ); else Response.Write( "User is not in Manager role<p>" ); if ( p.IsInRole("Employee") ) Response.Write( "User is in Employee role<p>" ); else Response.Write( "User is not in Employee role<p>" ); if ( p.IsInRole("Sales") ) Response.Write( "User is in Sales role<p>" ); else Response.Write( "User is not in Sales role<p>" ); 6. In Solution Explorer, right-click default.aspx, and then click Set As Start Page. 7. On the Build menu, click Build Solution. Eliminate any build errors. 8. Press Ctrl+F5 to run the application. Because default.aspx is configured as the start up page, this is the initially requested page. 9. When you are redirected to the logon page (because you do not initially have an authentication ticket), enter a user name and password (any will do), and then click Logon. 10. Confirm that you are redirected to default.aspx and that the user identity and the correct role details are displayed. The user should be a member of the Senior Manager, Manager, and Employee role, but not a member of the Sales role. Additional Resources For more information, see the following related How Tos in the Reference section of this guide: ● “How To: Use Forms Authentication with Active Directory” ● “How To: Use Forms Authentication with SQL Server 2000” How To: Implement Kerberos Delegation for Windows 2000 By default, the Microsoft® Windows® 2000 operating system uses the Kerberos protocol for authentication. This How To describes how to configure Kerberos delegation, a powerful feature that allows a server, while impersonating a client, to access remote resources on behalf of the client. Important: Delegation is a very powerful feature and is unconstrained on Windows 2000. It should be used with caution. Computers that are configured to support delegation should be under controlled access to prevent misuse of this feature. Windows .NET Server will support a constrained delegation feature. When a server impersonates a client, Kerberos authentication generates a delegate- level token (capable of being used to respond to network authentication challenges from remote computers) if the following conditions are met: 1. The client account that is being impersonated is not marked as sensitive and cannot be delegated in Microsoft Active Directory® directory service. 2. The server process account (the user account under which the server process is running, or the computer account if the process is running under the local SYSTEM account) is marked as trusted for delegation in Active Directory. Notes ● For Kerberos delegation to be successful, all computers (clients and servers) must be part of a single Active Directory forest. ● If you impersonate within serviced components and want to flow the callers context through an Enterprise Services application, the application server that hosts Enterprise Services must have Hotfix Rollup 18.1 or greater. For more information, see INFO: Availability of Windows 2000 Post-Service Pack 2 COM+ Hotfix Rollup Package 18.1. Building Secure ASP.NET Applications386 Requirements The following items describe the recommended hardware, software, network infrastructure, skills and knowledge and service packs you will need: Windows 2000 Server with Active Directory. Summary This How To includes the following procedures: 1. Confirm that the Client Account is Configured for Delegation 2. Confirm that the Server Process Account is Trusted for Delegation 1. Confirm that the Client Account is Configured for Delegation This procedure ensures that the client account is capable of being delegated.  To confirm that the client account is configured for delegation 1. Log onto the domain controller using an administrator account. 2. On the taskbar, click the Start button, point to Programs, point to Administra- tive Tools, and then click Active Directory Users and Computers. 3. Under your domain, click the Users folder. 4. Right-click the user account that is to be delegated, and then click Properties. 5. Click the Account tab. 6. Within the Account options list, make sure Account is sensitive and cannot be delegated is not selected. 7. Click OK to close the Properties dialog box. 2. Confirm that the Server Process Account is Trusted for Delegation This procedure ensures that the account used to run the server process (the process that performs impersonation) is allowed to delegate client accounts. You must configure the user account under which the server process runs, or if the process runs under the local SYSTEM account, you must configure the computer account. Perform the appropriate procedure that follows, depending on if your server process runs under a Windows account or a local SYSTEM account. How To: Implement Kerberos Delegation for Windows 2000 387  To confirm that the server process account is trusted for delegation if the server process runs under a Windows user account 1. Within the Users folder of Active Directory Users and Computers, right-click the user account that is used to run the server process that will impersonate the client, and then click Properties. 2. Click the Account tab. 3. Within the Account options list, click Account is trusted for delegation.  To confirm that the server process account is trusted for delegation if the server process runs under the local SYSTEM account 1. Right-click the Computers folder within Active Directory Users and Computers, and then click Properties. 2. Right-click the server computer (where the process that impersonates the client will be running), and then click Properties. 3. On the General page, click Trust computer for delegation. References ● For a list of the files that are affected by the Windows 2000 Post-Service Pack 2 (SP2) COM+ hotfix package 18.1, see article Q313582, “INFO: Availability of Windows 2000 Post-Service Pack 2 COM+ Hotfix Rollup Package 18.1,” in the Microsoft Knowledge Base. ● To see how to configure a complete delegation scenario, involving ASP.NET, Enterprise Services and SQL Server, see “Flowing the Original Caller to the Database” in Chapter 5, “Intranet Security.” How To: Implement IPrincipal The .NET Framework provides the WindowsPrincipal and GenericPrincipal classes, which provide basic role-checking functionality for Windows and non- Windows authentication mechanisms respectively. Both classes implement the IPrincipal interface. To be used for authorization, ASP.NET requires that these objects are stored in HttpContext.User. For Windows-based applications, they must be stored in Thread.CurrentPrincipal. The functionality offered by these classes is sufficient for most application scenarios. Applications can explicitly call the IPrincipal.IsInRole method to perform pro- grammatic role checks. The Demand method of the PrincipalPermission class, when used to demand that a caller belong to a particular role (either declaratively or imperatively) also results in a call to IPrincipal.IsInRole. In some circumstances, you might need to develop your own principal implementa- tions by creating a class that implements the IPrincipal interface. Any class that implements IPrincipal can be used for .NET authorization. Reasons for implementing your own IPrincipal class include: ● You want extended role checking functionality. You might want methods that allow you to check whether a particular user is a member of multiple roles. For example: CustomPrincipal.IsInAllRoles( "Role1", "Role2", "Role3" ) CustomPrincipal.IsInAnyRole( "Role1", "Role2", "Role3" ) ● You want to implement an extra method or property that returns a list of roles in an array. For example: string[] roles = CustomPrincipal.Roles; ● You want your application to enforce role hierarchy logic. For example, a Senior Manager may be considered higher up in the hierarchy than a Manager. This could be tested using methods like the following. CustomPrincipal.IsInHigherRole("Manager"); CustomPrincipal.IsInLowerRole("Manager"); Building Secure ASP.NET Applications390 ● You want to implement lazy initialization of the role lists. For example, you could dynamically load the role list only when a role check is requested. This How To describes how to implement a custom IPrincipal class and use it for role-based authorization in an ASP.NET application that uses Forms authentication. Requirements The following items describe the recommended hardware, software, network infrastructure, skills and knowledge, and service packs you will need: ● Microsoft® Visual Studio® .NET development system The procedures in this article also require that you have knowledge of ASP.NET Web development with the Microsoft Visual C#™ development tool. Summary This How To includes the following procedures: 1. Create a Simple Web Application 2. Configure the Web Application for Forms Authentication 3. Generate an Authentication Ticket for Authenticated Users 4. Create a Class that Implements and Extends IPrincipal 5. Create the CustomPrincipal Object 6. Test the Application 1. Create a Simple Web Application This procedure creates a new ASP.NET Web application. The application will contain two pages, a default page that only authenticated users are allowed to access and a logon page used to collect user credentials.  To create a simple Web application 1. Start Visual Studio .NET and create a new C# ASP.NET Web Application called CustomPrincipalApp. 2. Rename WebForm1.aspx to Logon.aspx. 3. Add the controls listed in Table 1 to Logon.aspx to create a logon form. How To: Implement IPrincipal 391 Table 1: Logon.aspx controls Control Type Text ID Label User Name: - Label Password - Text Box - txtUserName Text Box - txtPassword Button Logon btnLogon 4. Set the TextMode property of the password Text Box control to Password. 5. In Solution Explorer, right-click CustomPrincipalApp, point to Add, and then click Add Web Form. 6. Enter default.aspx as the new form’s name, and then click Open. 2. Configure the Web Application for Forms Authentication  To edit the application’s Web.config file to configure the application for Forms authentication 1. Use Solution Explorer to open Web.config. 2. Locate the <authentication> element and change the mode attribute to Forms. 3. Add the following <forms> element as a child of the <authentication> element and set the loginUrl, name, timeout, and path attributes as follows: <authentication mode="Forms"> <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/"> </forms> </authentication> 4. Add the following <authorization> element beneath the <authentication> element. This allows only authenticated users to access the application. The previously established loginUrl attribute of the <authentication> element redirects unauthenticated requests to the Logon.aspx page. <authorization> <deny users="?" /> <allow users="*" /> </authorization> [...]... can then be used from other managed applications such as ASP.NET Web applications, Web services and Enterprise Services applications For related How To articles that use the DPAPI library created in this article, see the following articles in the Reference section of this guide: q “How To: Use DPAPI (Machine Store) from ASP.NET q “How To: Use DPAPI (User Store) from ASP.NET with Enterprise Services”... solution configuration is shown in Figure 1 on the next page 416 Building Secure ASP.NET Applications Enterprise Services (COM+) Server Application ASP.NET Web Application 3 4 Serviced Component 6 5 2 Win32 Service Launch P/Invoke 1 Encrypted Connection String DPAPI Crypto API Start and load user profile Service Control Manager web.config Figure 1 ASP.NET Web application uses a serviced component in an Enterprise...392 Building Secure ASP.NET Applications 3 Generate an Authentication Ticket for Authenticated Users This procedure writes code to generate an authentication ticket for authenticated users The authentication ticket is a type of cookie used by the ASP.NET FormsAuthenticationModule The authentication code typically involves looking... CRYPTPROTECT_LOCAL_MACHINE flag to the DPAPI functions 400 Building Secure ASP.NET Applications q q The user profile approach affords an additional layer of security because it limits who can access the secret Only the user who encrypts the data can decrypt the data However, use of the user profile requires additional development effort when DPAPI is used from an ASP.NET Web application because you need to take... random value designed to make deciphering the secret more difficult.) The problem with using an additional entropy parameter is that this must be securely stored by the application, which presents another key management issue 410 Building Secure ASP.NET Applications Note: If you use DPAPI with the machine store, the encrypted string is specific to a given computer and therefore you must generate the... menu, click Build Solution to rebuild the projects 7 Right-click WebForm1.aspx, and then click View in Browser 8 Enter a database connection string such as the one that follows into the Data to Encrypt field server=(local);Integrated Security=SSPI; database=Northwind 414 Building Secure ASP.NET Applications 9 Click the Encrypt button 10 Select the encrypted cipher text and copy it to the clipboard 11... methods supported by the CustomPrincipal class if ( cp.IsInRole("Senior Manager") ) { Response.Write( cp.Identity.Name + " is in the " + "Senior Manager Role" ); Response.Write( "" ); } 3 98 Building Secure ASP.NET Applications if ( cp.IsInAnyRoles("Senior Manager", "Manager", "Employee", "Sales") ) { Response.Write( cp.Identity.Name + " is in one of the specified roles"); Response.Write( "" ); }... for an ASP.NET Web application that wants to use DPAPI with the user store: q Calls to DPAPI from an ASP.NET application running under the default ASPNET account will fail This is because the ASPNET account does not have a loaded user profile How To: Use DPAPI (User Store) from ASP.NET with Enterprise Services 417 q If an ASP.NET Web application is configured to impersonate its callers, the ASP.NET. .. private helper methods to the class private void InitPromptstruct(ref CRYPTPROTECT_PROMPTSTRUCT ps) { ps.cbSize = Marshal.SizeOf(typeof(CRYPTPROTECT_PROMPTSTRUCT)); ps.dwPromptFlags = 0; 406 Building Secure ASP.NET Applications ps.hwndApp = NullPtr; ps.szPrompt = null; } private unsafe static String GetErrorMessage(int errorCode) { int FORMAT_MESSAGE_ALLOCATE_BUFFER = 0x00000100; int FORMAT_MESSAGE_IGNORE_INSERTS... more information, see the following related How Tos: q “How To: Use DPAPI (Machine Store) from ASP.NET in the Reference section of this guide q “How To: Use DPAPI (User Store) from ASP.NET with Enterprise Services” in the Reference section of this guide How To: Use DPAPI (Machine Store) from ASP.NET Web applications often need to store security-sensitive data, such as database connection strings and . Hotfix Rollup 18. 1 or greater. For more information, see INFO: Availability of Windows 2000 Post-Service Pack 2 COM+ Hotfix Rollup Package 18. 1. Building Secure ASP. NET Applications3 86 Requirements The. Identity is: " + p.Identity.Name ); Response.Write( "<p>" ); Building Secure ASP. NET Applications3 84 5. Add the following code to test role membership for the current authenticated identity. if. Building Secure ASP. NET Applications3 82 4. Construct GenericPrincipal and FormsIdentity Objects This procedure implements