email article printer friendly get the code more resources

Secure Your Directory-Enabled Apps
Use Active Directory Application Mode and Windows Authorization Manager to add security, personalization, and application configuration to your applications easily.
by Enrico Sabbadin

Posted March 1, 2004

Technology Toolbox: VB.NET, ASP.NET, Windows Authorization Manager, Active Directory Application Mode, Active Directory

Implementing a robust security infrastructure around an application is one of the toughest tasks you can face in the design and development process. The job is even harder when your requirements call for the security infrastructure to have zero or low impact on the existing IT infrastructure. This requirement often leads to custom and ad-hoc security solutions that are difficult to implement correctly unless you're a highly experienced developer. A new capability in Active Directory (AD)—Active Directory Application Mode (ADAM)—and Windows Authorization Manager give you the tools to implement a robust solution that handles authentication, operation-based authorization, personalization, and application configuration for directory-enabled applications without resorting to a Windows Identity-based infrastructure. In this article, I'll introduce you to ADAM and Authorization Manager and show you how to use them to develop such a solution easily.

ADAM shares a storage engine (Directory System Agent [DSA]) and the protocol to access it (Lightweight Directory Access Protocol [LDAP]) with AD (see Figure 1). Unlike AD, ADAM doesn't run as an operating-system service. You can even install multiple ADAM instances on the same computer as long as they listen on different ports. Each ADAM instance manages an AD store that's divided into partitions. Every ADAM instance includes two system partitions—the schema partition and the configuration partition—and one or more application partitions. All partitions contain data in the form of objects in a hierarchical tree structure.

The configuration partition keeps track of the store's configuration information, including the existing partitions' names and the configuration set's properties, such as its replica scheduling (more about configuration sets later). The schema partition holds the definition of all the object types (and their attributes) you can create and store in that specific ADAM instance. In other words, each object in the directory is an instance of one or more classes defined in the schema partition. Each class comprises a set of attributes. Class and attribute definitions are actually object instances of the classSchema and attributeSchema classes, respectively. These classes then serve as the building blocks of the schema meta model. Note that no particular class owns attributes; you define them separately and then attach them to one or more classes as required.

Classes and attributes both come with a reach-metadata set of information that constrains and drives object instantiation. You can specify which attributes are mandatory and which are optional for each class, and you can specify which object types can be the parent of an instance of the class in the tree structure. Each attribute also has plenty of associated information, the most interesting of which is the attribute syntax (the attribute's data type), the attribute multiplicity (you can define single-value or multivalue attributes), and whether the attribute is indexed (for fastest queries).

Classes come in three types: structural, abstract, and auxiliary. You can instantiate only structural classes. One class can inherit from another one, thereby acquiring all the superclass's and possible superior classes' attributes. A class can also inherit from auxiliary classes. All classes must inherit directly or indirectly from the class named "top," which plays the same role in AD that System.Object does in .NET (see Additional Resources for more information on ADAM).