Export (0) Print
Expand All

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:

In addition to this introductory material, the documentation contains the following topics:

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:

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"); 

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.

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.

© 2014 Microsoft