User Interface Process (UIP) Application Block - Version 2.0
| Retired Content |
|---|
| This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
|
Microsoft Corporation
April 2004
Summary: Chapter 4 presents the steps for successful deployment, as well as the important security threats and countermeasures you need to consider.
Contents
Deployment Requirements
Deploying the UIP Application Block
Updating the UIP Application Block
Security Considerations
Conclusion
When you use the UIP Application Block with your applications, you need to ensure that the initial deployment of the block is planned and managed, and that subsequent updates are deployed with minimal impact to your existing environment.
This chapter describes how to deploy the UIP Application Block, how to update the block when future versions become available, and security considerations for the block.
Deployment Requirements
Before you can deploy the UIP Application Block on any computer, you need to install the Microsoft® .NET Framework version 1.1. In addition, if you want to use the SecureSqlServerPersistState class or the SqlServerPersistState class to persist state, you will also need Microsoft SQL Server. If you are using the block for Web applications, you need to install Internet Information Services (IIS).
Deploying the UIP Application Block
The UIP Application Block is implemented as a single assembly named Microsoft.ApplicationBlocks.UIProcess.dll. The block ships with and uses the Data Access Application Block, Microsoft.ApplicationBlocks.Data.dll. When you deploy the UIP Application Block, you must also deploy the Data Access Application Block.
Note The UIP Application Block ships with and has been tested with version 2.0 of the Data Access Application Block. Other versions of the Data Access Application Block are not guaranteed to work with the UIP Application Block, version 2.0.
For more information about the Data Access Application Block, see Data Access Application Block for .NET, available on MSDN. For more guidance on data access, see .NET Data Access Architecture Guide, available on MSDN.
You must deploy the UIP Application Block, your controller classes, and the Data Access Application Block on the same computer as the user interface components that they orchestrate. In a Web application, this means deploying the blocks and controllers on the Web servers. In a Microsoft® Windows® operating system-based application, you must deploy the blocks and controllers with the Windows Forms application.
Applications that use the UIP Application Block can be deployed in one of two configurations:
- As a private assembly in the application folder hierarchy
- As a shared assembly in any file system location or in the global assembly cache
Deploying the UIP Application Block as a Private Assembly
The UIP Application Block and the Data Access Application Block can be deployed in the application directory structure. This simplifies deployment because you can use the xcopy command to install the entire application (including the UIP Application Block and the Data Access Application Block) on the target computer.
If multiple applications on the same computer use the blocks, you can install a copy of the assembly in each application folder hierarchy. This allows each application's copy of the assembly to be updated independently.
Deploying the UIP Application Block as a Shared Assembly
You can deploy shared assemblies in the global assembly cache, which allows all applications on the computer to use the assembly without any further configuration. The global assembly cache also provides support for Component Object Model (COM) interoperability, component services (such as transaction management), and versioning management.
You can use one of the following tools to install an assembly in the global assembly cache:
- An installer utility, such as the Microsoft Windows Installer, version 2.0
- The Global Assembly Cache Tool command line utility (Gacutil.exe)
- The .NET Admin Microsoft Management Console (MMC) snap-in (Mscorcfg.msc)
To install the UIP Application Block and Data Access Application Block in the global assembly cache, you must first generate a strong name key, sign the assemblies, and then install them in the global assembly cache in the correct order.
Once you have installed the assemblies in the global assembly cache, you will need to make changes to your application configuration file. In the configuration file, the <iViewManager>, <state>, <controller>, <layoutManager>, and <statePersistenceProvider> in the <objectTypes> section each have a setting called PublicKeyToken in the type attribute. This is normally set to null, but if your UIP assembly is in the global assembly cache, you must set the PublicKeyToken equal to the public key token value associated with the UIP assembly in the global assembly cache.
To sign the assemblies and add them to the global assembly cache
- Use Sn.exe to generate a key for the Microsoft.ApplicationBlocks.Data assembly.
- Edit the AssemblyInfo.cs file in the Microsoft.ApplicationBlocks.Data assembly to reference the key file.
- Rebuild the Microsoft.ApplicationBlocks.Data assembly.
- Use Gacutil.exe or the .NET Microsoft Management Console (MMC) snap-in to add the Microsoft.ApplicationBlocks.Data assembly to the global assembly cache.
- Use Sn.exe to generate a key for the Microsoft.ApplicationBlocks.UIProcess assembly.
- Remove and then add the reference to the Microsoft.ApplicationBlocks.Data assembly in the Microsoft.ApplicationBlocks.UIProcess assembly.
- Edit the AssemblyInfo.cs file in the Microsoft.ApplicationBlocks.UIProcess assembly to reference the key file.
- Rebuild the Microsoft.ApplicationBlocks.UIProcess assembly.
- Use Gacutil.exe or the .NET Microsoft Management Console (MMC) snap-in to add the Microsoft.ApplicationBlocks.UIProcess to the global assembly cache.
For more information, see the following:
- "Deploying .NET Framework-based Applications".
- "Deploying Applications," from the .NET Framework Developer's Guide.
Updating the UIP Application Block
If an upgraded version of the UIP Application Block becomes available, you will need to determine whether the new version introduces compatibility problems for some of your applications. Install the new version of the block where appropriate. Exactly what procedure you use will depend on whether the assembly is private or in the global assembly cache.
Updating Private Assemblies
If the UIP Application Block assembly has been deployed as a private assembly, you can deploy the upgrade by simply replacing the old version of the dynamic-link library (DLL) with the new one.
Note You should keep a copy of the old version so that if you encounter any compatibility issues with the new assembly, you can revert to the earlier version.
Updating Shared Assemblies
If multiple applications use the UIP Application Block, install the updated assembly in the global assembly cache. By default, the .NET runtime attempts to load the assembly that has the latest build and revision numbers and the same major and minor revision numbers as the assembly with which the application was built. Therefore, if the major and minor revision numbers have not changed, adding a later version to the global assembly cache should automatically upgrade all applications that refer to the UIP Application Block assembly.
If the major or minor revision numbers have been incremented, or if the new version causes compatibility issues with existing applications, you can override the default version policy. To specify that an application should use a particular version of an assembly, edit the BindingPolicy section of the application configuration file (for individual applications) or the machine policy file. Alternatively, you can distribute the new version of the assembly with a publisher policy file to redirect assembly requests to the new version.
Note For more information about versioning in .NET, see the MSDN article, "Simplifying Deployment and Solving DLL Hell with the .NET Framework," at http://msdn.microsoft.com/en-us/library/ms973843.aspx.
See Also
For more information, refer to the following:
- "How the Runtime Locates Assemblies," from the .NET Framework Developer's Guide.
- "Redirecting Assembly Versions," from the .NET Framework Developer's Guide.
- "Specifying an Assembly's Location," from the .NET Framework Developer's Guide.
Security Considerations
If you deploy applications that use the UIP Application Block, you should be aware of the security considerations that surround block deployment.
SQL Server Security
The UIP Application Block allows you to persist state in a SQL Server database. The connection information is declared in the application configuration file, meaning that you must ensure that the contents of this file do not expose your SQL Server computer to unauthorized users.
SQL Server provides two modes of authentication: Windows authentication mode integrates SQL Server with Microsoft® Windows® operating system security; whereas mixed mode allows both Windows accounts and SQL Server logins to be used. Where possible, you should run your SQL Server computer in Windows authentication mode. This means that no user-specific information needs to be stored in the configuration file because the SQL Server computer will use the Windows information for authentication.
The classes in the UIP Application Block use the Data Access Application Block to access the SQL Server database. For more information about security issues when using the Data Access Application Block, see Data Access Application Block for .NET.
Configuration File Security
The application configuration file may contain sensitive information, such as the SQL Server name and the database name. You can secure application configuration files by using Windows NTFS file permissions. In an ASP.NET-based application, the runtime prevents access to the Web.config file, although you can enhance this protection with NTFS permissions.
For more information about securing applications, see "Securing Applications," from the .NET Framework Developer's Guide.
Security Permissions
If you are not working in a full trust environment, you will need to grant specific permissions to several of the classes. Table 4.1 shows the UIP classes that require security permissions.
Table 4.1: UIP Security Permissions
| Class | Permission Type | Comment |
|---|---|---|
| CryptHelper | RegistryPermission | |
| IsolatedStoragePersistence | IsolatedStorageFilePermission | |
| SqlServerPersistState | SqlClientPermission | |
| SecureSqlServerPersistState | SqlClientPermission | |
| State | SecurityPermissionAttribute(Demand, SerializationFormatter=True) | demand, Serialization permissions |
| State | SecurityPermissionAttribute (LinkDemand, Flags=SecurityPermissionFlag. SerializationFormatter) | immediate caller requires serialization permissions |
| GenericFactory | ReflectionPermission |
Note For more information about code access security, see "Security Policy Best Practices," from the .NET Framework Developer's Guide.
Security Threats and Countermeasures
The UIP Application Block is designed to provide you with reusable code that meets the security requirements of customers. It is important to identify areas where threats exist, as well as appropriate countermeasures to those threats. You should use the results of your risk analysis to determine whether the countermeasures are necessary in your environment. This section addresses several security threats that could be introduced by the UIP Application Block, but does not comprehensively cover security issues for Web or Windows Forms applications that use the block.
The main asset that needs to be protected as part of the block is the data stored in the State object. You may store sensitive information, such as credit card information, that needs to be secured.
Table 4.2 identifies the threats to these assets, along with appropriate countermeasures.
Note The countermeasures listed in Table 4.2 have not been implemented in the UIP Application Block. You should analyze the risk posed by these threats, and where appropriate, implement the countermeasures to mitigate the risk.
Table 4.2: User Interface Process Block Threats and Countermeasures
Threat: State object is exposed after being persisted
| Threat target | The State object |
| Risk | The State object holds the business logic information and is persisted by the StatePersistenceProvider. |
| Attack techniques | Depends on the type of StatePersistenceProvider. |
| Countermeasures | Each StatePersistenceProvider needs to secure the data. The IsolatedStoragePersistState persistence provider includes certain security features, such as requiring the IsolatedStorageFilePermission for certain operations. |
Threat: Malicious assemblies are loaded during runtime
| Threat target | An application that uses the UIP Application Block |
| Risk | Because UIP relies heavily on the configuration file, the configuration file can be used as a break-in point for hackers. UIP uses the configuration information to dynamically load assemblies. Additionally, critical information, such as the SQL Server connection string, is stored in the configuration file. This information is at risk because it is in plain text format. |
| Attack techniques | The attacker deploys malicious assemblies on the client and alters the configuration file to force UIP to load the malicious assemblies. The attacker can then take control of the workflow. |
| Countermeasures |
|
Threat: Malicious assemblies use reflection to create class instances
| Threat target | A system that runs the UIP Application Block and holds the user data. |
| Risk | Malicious code could compromise Factory classes in the block that use reflection, and create an instance of another class. |
| Attack techniques |
|
| Countermeasures | Demand ReflectionPermission on all code that uses reflection. |
Conclusion
Once you have developed applications that use the UIP Application Block, you are in a position to deploy them. However, it is important to ensure that you think about deployment considerations during application development. You need to ensure that your environment has the prerequisites to install the block, and then determine how and where you will install the assemblies contained in the block. Any time you deploy new code in your environment, you should think about the security implications of the deployment, and take appropriate measures to minimize any threats that you face. By using the information contained in this chapter, you increase the likelihood that you can successfully deploy and run your applications.
| Retired Content |
|---|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
