Scenarios and Goals of the Security Application Block

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 scenarios are the following:

• Obtaining a temporary token for an authenticated user
• Authenticating a user using a token
• Ending a user session (expire a token)
• Determining if a user is authorized to perform a task

  For more information about each of these scenarios, see Key Scenarios 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. Posted in: .NET Framework MS Windows Software Programming| Tags: Best Practice .NET asp.net Enterprise Library Application Validation Application Block C# Benefit

---

the Strong Exception Guarantee

When you throw an exception, you've introduced a disruptive event into the application. Control flow has been compromised. Expected actions did not occur. Worse, you've left the cleanup operation to the programmer writing the code that eventually catches the exception. The actions available when you catch exceptions are directly related to how well you manage program state when an exception gets thrown. Thankfully, the C# community does not need to create its own strategies for exception safety; the C++ community did all the hard work for us. Starting with Tom Cargill's article "Exception Handling: A False Sense of Security," and continuing with writings by Herb Sutter, Scott Meyers, Matt Austern, Greg Colvin, and Dave Abrahams, the C++ community developed a series of best practices that we can adapt to C# applications. The discussions on exception handling occurred over the course of 6 years, from 1994 to 2000. They discussed, debated, and examined many twists on a difficult problem. We should leverage all that hard work in C#.

Dave Abrahams defined three exception-safe guarantees: the basic guarantee, the strong guarantee, and the no-throw guarantee. Herb Sutter discussed these guarantees in his book Exceptional C++ (Addison-Wesley, 2000). The basic guarantee states that no resources are leaked and all objects are in a valid state after your application throws an exception. The strong exception guarantee builds on the basic guarantee and adds that if an exception occurs, the program state did not change. The no-throw guarantee states that an operation never fails, from which it follows that a method does not ever throw exceptions. The strong exception guarantee provides the best trade-off between recovering from exceptions and simplifying exception handling.

The basic guarantee happens almost by default in .NET and C#. The environment handles memory management. The only way you can leak resources due to exceptions is to throw an exception while you own a resource that implements IDisposable. Item 18 explains how to avoid leaking resources in the face of exceptions.

The strong guarantee states that if an operation terminates because of an exception, program state remains unchanged. Either an operation completes or it does not modify program state; there is no middle ground. The advantage of the strong guarantee is that you can more easily continue execution after catching an exception when the strong guarantee is followed. Anytime you catch an exception, whatever operation was attempted did not occur. It did not start, and it did not make some changes. The state of the program is as though you did not start the action.

Many of the recommendations I made earlier will help ensure that you meet the strong exception guarantee. Data elements that your program uses should be stored in immutable value types (see Items 6 and 7). If you combine those two items, any modification to program state can easily take place after performing any operation that might throw an exception. The general guideline is to perform any data modifications in the following manner:

1. Make defensive copies of data that will be modified.

2. Perform any modifications to these defensive copies of the data. This includes any operations that might throw an exception.

3. Swap the temporary copies back to the original. This operation cannot throw an exception.

Posted in: .NET Framework| Tags: Application C# Strong Exception Guarantee

---

how to incorporate the Validation Application Block into your application

To prepare your application

1. Add a reference to the Validation Application Block assembly. In Visual Studio, right-click your project node in Solution Explorer, and then click Add References. Click the Browse tab and find the location of the Microsoft.Practices.EnterpriseLibrary.Validation.dll assembly. Select the assembly, and then click OK to add the reference.
2. Use the same procedure to set a reference to the Enterprise Library Common assembly, named Microsoft.Practices.EnterpriseLibrary.Common.dll.
3. Follow the same procedure to set a reference to the ObjectBuilder assembly, Microsoft.Practices.EnterpriseLibrary.ObjectBuilder 2 .dll.
4. If you are using the ASP.NET, Windows Forms, or WCF integration assemblies, add one of the following references as appropriate.
   • Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WinForms.dll
   • Microsoft.Practices.EnterpriseLibrary.Validation.Integration.AspNet.dll
   • Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF.dll
5. (Optional) To use elements from the Validation Application Block without fully qualifying the type with the namespace, add the following using statements (C#) or Imports statements (Visual Basic) to the top of your source code file.

   C#
   

   using Microsoft.Practices.EnterpriseLibrary.Validation;
   using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;

   Visual Basic
   

   Imports Microsoft.Practices.EnterpriseLibrary.Validation
   Imports Microsoft.Practices.EnterpriseLibrary.Validation.Validators

Note:

For Visual Basic projects, you can use the References page of the Project Designer to manage references and imported namespaces. To access the References page, select a project node in Solution Explorer. On the Project menu, click Properties. When the Project Designer appears, click the References tab.

Posted in: .NET Framework| Tags: Reference Block Application Validation Application Block Validation Incorporate Coding Assembly Microsoft click dll integration enterpriselibrary

---

The Validation Application Block in Enterprise Library 4.1

The Enterprise Library Validation Application Block provides useful features that allow developers to implement structured and easy-to-maintain validation scenarios in their applications. Any application that accepts input either from users or from other systems must ensure that the information is valid in terms of some set of rules that you specify. For example, when processing an order, you may need to check that a customer's phone number has the correct number of digits or that a date falls within a particular range. In addition, if the validation fails, you may need to send an error message that explains what is wrong.

The Enterprise Library Validation Application Block provides a library of classes named validators, which implement functionality for validating .NET Framework data types. For example, one validator checks for null strings and another validator checks that a number falls within a specified range.

There are also special validators named AndCompositeValidator and OrCompositeValidator. If you create an AndCompositeValidator, which aggregates other validators, all validators in the composite validator must return T rue for successful validation. If you create an OrCompositeValidator, at least one of the validators in the composite validator must return T rue for successful validation.

You can also group validators together in a rule set. A rule set allows you to validate a complex object or graph by composing different validators of different types and applying them to elements in the object graph. Examples of these elements include fields, properties, and nested objects.

By using the Validation Application Block, you can perform validation and create rule sets in the following three ways:

• Using configuration
• Using attributes
• Using code

In addition, the Validation Application Block includes adapters that allow you to use the application block with the following technologies:

• ASP.NET
• Windows Forms
• Windows Communications Framework (WCF)

Posted in: .NET Framework| Tags: Enterprise Library Block Application Validation Application Block Validation number example enterprise rule validator library range

---