Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 40 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
40
Dung lượng
609,33 KB
Nội dung
End Try We can now save the personalization value(s) in the user's Session object so we can access them within the application pages without having to keep going back to the database. We also tell ASP.NET to create the authentication cookie and redirect the user back to the page they originally requested: If blnIsAuthenticated Then 'save background color in Session object Session("BGColor") = strBGColor ' save other personalization settings here 'redirect user to original page FormsAuthentication.RedirectFromLoginPage(strUsr, chkPersist.Checked) Else outMessage.InnerHtml = "<b>Invalid credentials</b> please re-enter " End If End Sub The Personalized default.aspx Page Following a successful login, the user is redirected to the page default.aspx. In it, we display their user name. We also include the same Log Off button - we won't be describing those features again here. What is different is the way that we set the background color of the page, and display an appropriate set of hyperlinks depending on the current username. The opening <body> tag in the page includes a bgcolor attribute, with the value set to a variable named strColor: <body bgcolor="<% = strColor %>"> This variable is declared in the <script> section of the page, and so is globally available throughout the page: <script language="VB" runat="server"> Dim strColor As String </script> We placed five ASP:Hyperlink elements within the body of the page to create the HTML hyperlinks you can see in the screenshots above. The last three of these have their Visible property set to False so they won't normally be visible in the final page: <ASP:Hyperlink id="lnkUser1" Text="Change Display Settings" NavigateUrl="http://dummy" runat="server" /><br /> <ASP:Hyperlink id="lnkUser2" Text="Change Sound Options" NavigateUrl="http://dummy" runat="server" /><br /> <ASP:Hyperlink id="lnkAdmin1" Text="Manage All Users" Visible="False" NavigateUrl="http://dummy" runat="server" /><br /> <ASP:Hyperlink id="lnkAdmin2" Text="Change Application Settings" Visible="False" NavigateUrl="http://dummy" runat="server" /><br /> <ASP:Hyperlink id="lnkAdmin3" Text="Display User Session Details" Visible="False" NavigateUrl="http://dummy" runat="server" /><br /> The <script> section of the page also contains an event handler that executes as the page is being created in response to the Page-Load event. This first checks that the user has been authenticated, and if so displays the authenticated user name: Sub Page_Load() If User.Identity.IsAuthenticated Then 'display welcome message msgHello.InnerHtml = "Hello <b>" & User.Identity.Name & "</b>" Next, it extracts the BGColor value from the user's Session (stored there when they submitted their login details) and sets the strColor variable so that the background color of the page is set to the appropriate color for this user: 'set preferred background color to the value that was 'saved in this user's Session object by the "login" page strColor = Session("BGColor") Now we can use the current login username to see if we should display the "administration" hyperlinks. In our example, we only display them if the user is sarahware: 'if user is "sarahware" display admin hyperlinks in page If User.Identity.Name = "sarahware" Then lnkAdmin1.Visible = True lnkAdmin2.Visible = True lnkAdmin3.Visible = True End If Other Personalization and Programmatic Security Options This is a very simple example of personalization and programmatic security, but you can see how it can easily be extended. For example we could: Include more personalization options, such as the text color, font size and style, page layout, page content, etc. Include a page containing form controls where the user can select the personalization options and values, and then use a SQL statement or stored procedure to update these in the database. Store a custom "role" name for each user in the database table, giving us the ability to allocate users to separate "roles" (rather like Windows account groups). We could then extract the role name for each user as they log in and perform programmatic security checks using this role name rather than the username. ASP.NET Process Model and Trust Levels We've mentioned several times in this chapter how ASP.NET pages and associated resources such as Web Services, User Controls, Components, etc., run under the special ASP.NET process account named ASPNET by default (if impersonation is not enabled). This account has broadly the same privileges as the IUSR_machinename account that is created when IIS is installed (as used with ASP 3.0). However it has extra privileges granted beyond that of the IUSR account, due to the fact that ASP.NET takes advantage of dynamic compilation and disk caching features. Also, by default ("out of the box"), ASP.NET runs in a mode called Full Trust level, which applies few security limits on the code that can be executed. This is fine for an Intranet scenario or a development machine, but once we place the server on the Internet we should consider reducing the permissions available to the process that the ASP.NET pages are running under. There are several different ways that we can configure reduced permissions in ASP.NET. They all revolve around the ultimate decision that we have to make - which account should we run the pages under? Once we know which account is being used, or specify the one that we want to use, we can use the Windows ACLs on all the resources on our machine to limit and control access. We can also control access permissions to access other applications and services by changing the trust level. We'll come back to this shortly. The ASPNET Process Account To be able to generate Intermediate Language (IL) code and binary executable files using the compilers included with the .NET Framework, the account under which the page executes requires more permissions than the equivalent in ASP 3.0. To accomplish this, an account named ASPNET is created by the ASP.NET setup routine. This account is automatically configured with the following access privileges: The ASP.NET installation folder hierarchy (%installroot%). This is where the .NET Framework assemblies and machine configuration files reside. By default the ASPNET account has READ access to these folders. If you configure an application to use impersonation (i.e. run under a different account), or change the process account within the <processModel> section of config.web, the "Process Model" account you use must have READ access to these folders. The folder used for dynamic compilation of ASP.NET pages and resources. The root folder for this is %installroot%\ASP.NET Temporary Files. Application code generation occurs in a discrete directory beneath this folder for each application (the location of this root folder can be configured using the tempDir attribute of the <compilation> section of config.web). By default the ASPNET account has READ/WRITE access to these folders. If you configure an application to use impersonation (i.e. run under a different account), or change the process account within the <processModel> section of config.web, the account you use must have READ/WRITE access to these folders. The Global Assembly Cache (GAC) folder, where shared assemblies are located (usually %windir%\assembly). By default the ASPNET account has READ access to this folder. If you configure an application to use impersonation (i.e. run under a different account), or change the process account within the <processModel> section of config.web, the account you use must have READ access to this folder. The folder used by Web Services to generate serialization proxies. By default this is %windir%\temp, and the ASPNET account has READ/WRITE access to this folder. If you change the process account within the <processModel> section of config.web, the account you use must have READ/WRITE access to this folder. The Default Web Site root folder (usually %systemdrive%\inetpub\wwwroot) and its subfolders. By default the ASPNET account has READ access to these folders. If you configure an application to use impersonation (i.e. run under a different account), or change the process account within the <processModel> section of config.web, the account you use must have READ access to these folders. If you want to write to the disk from an ASP.NET page or other resource, you must enable WRITE permission for the target folder as well (in the same way as was required under ASP 3.0). ASP.NET will try to read a configuration file located at \inetpub\wwwroot\web.config, and perform change monitoring on that directory. Your own application directories, where the application content resides. By default the ASPNET account has READ access to these folders. If you configure an application to use impersonation (i.e. run under a different account), or change the process account within the <processModel> section of config.web, the account you use must have READ access to these folders. By default ("out of the box"), ASP.NET runs in a mode called Full Trust level, which applies few security limits on the code that can be executed. This is fine for an Intranet scenario or a development machine, but once we place the server on the Internet we should consider reducing the permissions that are available to the process running the ASP.NET pages. There are several different ways that we can configure reduced permissions in ASP.NET. They all revolve around the ultimate decision that we have to make - which account should we run the pages under? Once we know which account is being used, or specify the one that we want to use, we can use the Windows ACLs on all the resources on our machine to limit and control access. We can also control access with the <processModel> element in machine.config (or in a web.config file placed in the application directory). This specifies which account is used when impersonation is not enabled: <processModel enable="[true | false]" userName="[user]" password="[AutoGenerate | password]" /> The default settings in machine.config are: <processModel enable="true" userName="machine" password="AutoGenerate" /> So, by default, all our ASP.NET pages and resources will be executed under the special process account - the account with the "moniker" of ASPNET. This account generally has appropriate permissions set by default that allow ASP.NET pages and resources to execute. And by modifying the permissions that this account has we can thereby control how ASP.NET will be able to access specified resources. For example, to be able to write to the server's disk, the ASPNET account must have WRITE access permission for the target folder. However, there is another "moniker" value you can use here instead, namely " system", and with the password also set to " AutoGenerate". This causes ASP.NET to run under a local SYSTEM account (as in Beta 2). To run ASP.NET under the SYSTEM account, change the <processModel> element attributes as follows: <processModel enable="true" userName="system" password="AutoGenerate" /> An alternative is to specify that ASP.NET pages and resources should be processed under the context of some other Windows account by changing the userName and password values in the <processModel> element - either for the entire machine (in machine.config), or for a specific application directory. As a trivial example, we can run our ASP.NET pages and resources under an account that we create named " MyProcess" with the password "secret" by specifying this account: <processModel enable="true" userName="MyProcess" password="secret" /> Note that the settings specified in the <processModel> element are only applicable to ASP.NET, and do not affect other types of application or service running under the .NET Framework. The Identity Element and Impersonation The <processModel> element provides account details that are used only when impersonation is not enabled. Recall from our discussions near the start of this chapter that turning on impersonation means that ASP.NET will run under the context of the account that is authenticated by IIS when a request is received. If IIS is configured to allow anonymous access (the default for a Web site), then the context is that of the IUSR account (or the account you specified that IIS use for anonymous access if you changed this). Simply adding the <identity impersonate="true"> element within the <system.web> section of the machine.config or web.config files means that anonymous access will take place under the IIS anonymous account ( IUSR_machinename) <system.web> <identity impersonate="true" /> </system.web> Another possibility is to use the userName and password attributes of the <identity> element to specify the account that we want ASP.NET resources to be executed under. In this case we also set the impersonate attribute to "true": <system.web> <identity impersonate="true" userName="account-name" password="account-password" /> </system.web> Note that the settings specified in the <identity> element are applicable only to ASP.NET, and not to the rest of the .NET Framework. You also might like to consider the wisdom of using this last option where the password must be stored in the file as plain text. In fact there is a little more to it than this. The <processModel> element specifies the account under which the worker process is run when it's enabled (it's not in IIS6 in native mode, for example). All threads start as the specified account. When impersonation is enabled, they temporarily take on the impersonated context. Calling the RevertToSelf method will always get back to the process account. There are a couple of events that fire without a Request context being available, such as Application_OnEnd, and these always run with the ASPNET process account identity regardless of impersonation. Specifying the Trust Level There is another option for controlling the permissions for ASP.NET to process resources. This takes advantage of the <trust> element in machine.config, and it can be used to set a more stringent "trust level". The default setting is " Full", specified by this line from the default machine.config file: <trust level="Full" originUrl="" /> The other options are "High", "Low", and "None", and these apply progressively more stringent limitations on the permissions that code running under the .NET Framework will have. The <securityPolicy> element specifies which security configuration file applies to each of the trust levels: <securityPolicy> <trustLevel name="Full" policyFile="internal" /> <trustLevel name="High" policyFile="web_hightrust.config" /> <trustLevel name="Low" policyFile="web_lowtrust.config" /> <trustLevel name="None" policyFile="web_notrust.config" /> </securityPolicy> Each of these files has sections that describe the permissions that are available to .NET framework applications and code. Some examples of the permissions that can be set are: Which environment variables the code can query Which directories the code can write to through the file I/O classes Whether DNS enquiries are allowed Whether blank passwords can be used with the ADO.NET data providers Whether messages can be sent to, and received from, the Message Queue Service Whether access to a printer is permitted Which performance counters can be accessed You can change the trust level and edit the "trust" configuration files to finely control the permissions available to your code and resources. Remember that the settings specified in the <trust> element are applicable to the whole of the .NET framework, not just ASP.NET. A simple configuration Wizard is provided with the Frameworks that can be used to change the trust level. Select Programs | Administrative Tools | Microsoft .NET Framework Wizards , and select the "Adjust .NET Security" icon: *** Insert picture: 4885v2-14-90.bmp [...]... in! The topic list for this chapter was: An overview of the security model in Windows 2000 and IIS An overview of the new security features in ASP.NET The different types of access control that we can implement with ASP.NET A detailed look at how we apply the ASP.NET security and access control features A brief overview of the "trust" model Web application security is based around the three fundamental... user) We looked at each topic in turn, and saw how they are implemented and configured in IIS, in Windows 2000, and in ASP.NET We also saw the whole chain of events that occur as part of the overall process, and the various access control options that they provide We then concentrated on ASP.NET security configuration, and saw how our three fundamental concepts are implemented through the web.config files... movieList = (ArrayList) ViewState["movies"]; } else { movieList = new ArrayList(); ViewState["movies"] = movieList; } } Now, the ASP.NET page framework will persist the state held in the ArrayList as part of the HTML page returned to the client When the next postback of that page occurs, ASP.NET will automatically recreate the ArrayList, restore its state, and make it available to our page This approach allows... common data structures such as lists, queues, stacks, and dictionaries Have a working knowledge of the most important collection interfaces and classes in the System.Collections and System.Collection.Specialized namespaces Know how to build your own strongly-typed collection classes For the examples in this chapter, I used a virtual directory in IIS called Collections to map to the Collections directory... examples in this chapter is available from http://www.wrox.com/), we'll just review the important elements The application looks like this (in this case three movies have been added to an unsorted list): The ASP.NET page responsible for rendering the page (excluding the server-side code for events) follows (written using C#): Movies in List . 200 0 and IIS. An overview of the new security features in ASP. NET. The different types of access control that we can implement with ASP. NET. A detailed look at how we apply the ASP. NET. in ASP 3 .0. To accomplish this, an account named ASPNET is created by the ASP. NET setup routine. This account is automatically configured with the following access privileges: The ASP. NET. to the disk from an ASP. NET page or other resource, you must enable WRITE permission for the target folder as well (in the same way as was required under ASP 3 .0) . ASP. NET will try to read