Introduction to the Security Application Block
| 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. |
| The latest Enterprise Library information can be found at the Enterprise Library site. |
This topic includes a series of brief sections that provide information to help you decide whether the Security Application Block is suitable for your requirements. This topic includes the following sections:
- Common Scenarios
- Example Application Code
- When to Use the Security Application Block
In addition to this introductory material, the documentation contains the following topics:
- Developing Applications Using the Security Application Block. This topic explains how to configure the application block to perform common tasks and how to use the application block in your applications.
- Key Scenarios. This topic demonstrates how to use the application block to perform the most typical security operations.
- Design of the Security Application Block. This topic explains the decisions that went into designing the application block and the rationale behind those decisions.
- Extending and Modifying the Security Application Block. This topic explains how to extend the application block by creating your own providers and how to modify the source code.
- Deployment and Operations. This topic explains how to deploy and update the application block's assemblies and also contains information about configuration.
- Security QuickStart. This topic explains how to install and configure the QuickStart applications and contains a series of walkthroughs that demonstrate how to incorporate common security operations into an application.
For details of the system requirements for the Security Application Block, see System Requirements. For details of the dependencies for the Security Application Block, see Application Block Dependencies.
Common Scenarios
Developers frequently write applications that must authorize users using one or more security providers such as Microsoft Active Directory directory service, Authorization Manager, Active Directory Application Mode (ADAM), and custom authorization providers. These applications may also need to cache authentication or authorization data for the duration of a logon session.
The Security Application Block simplifies these tasks by handling them in a consistent manner, abstracting the application code from the specific security providers. You can even change underlying providers through configuration without changing the underlying application code.
The Security Application Block provides code that will help you with the following scenarios:
- Authorization
- Caching security-related credentials
The Security Application Block is designed to address the most common tasks developers face when they are writing applications that require security functionality. These tasks have been arranged according to scenarios. Each scenario gives an example of a real-world situation, such as authenticating a user, discusses the security functions the situation requires, and shows the code that accomplishes the task.
The goal of arranging these tasks according to scenarios is to give the code some context. Instead of showing an isolated group of methods, with no sense of where they can best be used, scenarios provide a setting for the code, putting it in situations familiar to many developers whose applications must use security features.
The Key Scenarios section includes the following scenarios:
- Obtaining a Temporary Token for an Authenticated User
- Authenticating a User Using a Token
- Terminating a User Session (Expiring a Token)
- Determining Whether a User is Authorized to Perform a Task
Example Application Code
The following code shows how to determine if a user is authorized to perform a task.
IPrincipal principal = new GenericPrincipal(new GenericIdentity("Username"), new string[]{"Manager"});
IAuthorizationProvider ruleProvider = AuthorizationFactory.GetAuthorizationProvider("RuleProvider");
// Determine whether user is authorized for the rule defined as "Print Document".
bool authorized = ruleProvider.Authorize(principal, "Print Document");
'Usage
Dim principal As IPrincipal = New GenericPrincipal(New GenericIdentity("Username"), New String() {"Manager"})
Dim ruleProvider As IAuthorizationProvider = AuthorizationFactory.GetAuthorizationProvider("RuleProvider")
' Determine whether user is authorized for the rule defined as "Print Document".
Dim authorized As Boolean = ruleProvider.Authorize(principal, "Print Document")
Note
The code shown above uses a factory class in the Security Application Block to obtain an instance of the authorization provider it requires. As an alternative, you can use the Unity Integration approach to create instances of the objects in the Security Application Block. For more details of the integration of Enterprise Library and the Unity Application Block, see Creating Objects Using the Unity Application Block.
When to Use the Security Application Block
The Security Application Block includes implementations of the following functions:
- Authorization
- Security-related caching and session management
If your applications require the provided implementations, you can use the application block to provide this functionality. However, the application block is also designed to be extensible and includes generic providers for each function. You can adapt the providers to meet your own security requirements.
Note
If you use the Security Application Block to cache security-related information, the default caching store provider for the security cache is the Caching Application Block. Although the Caching Application Block can be configured to encrypt cache data in backing stores, the application block does not support encryption of cache data stored in memory. If an attacker compromises the computer and accesses the memory of your process, he or she can access information stored in the cache. If this threat is significant for your application, you should avoid storing sensitive information such as credit card numbers or passwords in the cache or use an alternate caching store provider that supports in-memory encryption.