|
|
Access to intranet applications is restricted to a limited group of authorized users (such as employees that belong to a domain). While an intranet setting limits the exposure of your application, you may still face several challenges when you develop authentication, authorization, and secure communication strategies. For example, you may have non-trusting domains, which make it difficult to flow a caller’s security context and identity through to the back-end resources within your system. You may also be operating within a heterogeneous environment with mixed browser types. This makes it more difficult to use a common authentication mechanism.
If you have a homogenous intranet where all computers run the Microsoft® Windows® 2000 operating system or later and you have a domain where users are trusted for delegation, delegation of the original caller’s security context to the back end becomes an option.
You must also consider secure communication. Despite the fact that your application runs in an intranet environment, you cannot consider the data sent over the network secure. It is likely that you will need to secure the data sent between browsers and the Web server in addition to data sent between application servers and databases.
The following common intranet scenarios are used in this chapter to illustrate key authentication, authorization, and secure communication techniques:
ASP.NET to SQL Server
ASP.NET to Enterprise Services to SQL Server
ASP.NET to Web Services to SQL Server
ASP.NET to Remoting to SQL Server
In addition, this chapter describes a Windows 2000 delegation scenario (Flowing the Original Caller to the Database), in which the original caller’s security context and identity flows at the operating system level from browser to database using intermediate Web and application servers.
| Note |
Several scenarios described in this chapter change the password of the default ASPNET account to allow duplicated accounts to be created on remote computers for network authentication purposes. This requires an update to the <processModel> element of Machine.config. <processModel> credentials should not be stored in plain text in machine.config. Instead use the aspnet_setreg.exe utility to store encrypted credentials in the registry. For more information, see Chapter 8, “ASP.NET Security” and article Q329290, “HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings” in the Microsoft Knowledge Base. |
|
|