Application Security, Part 4

What we are hearing from our customers is that they want their applications to become better corporate citizens. They want them to rely on user data in a global directory service, rather than adding their own proprietary repository of that data to the enterprise. Their computer security depends on it. So, over the next few posts, I am going to be covering technologies that are intended to help one meet that requirement.

 

Okay, so let’s think through the problem from the beginning. Our challenge is application security, which involves authentication—controlling who can access our application—and authorization—controlling what authenticated users can do within it. So, we know that we need to store information about our users—at the very least, we need to know who they are—and we know that such information belongs in the global directory service of the enterprise.

 

However, we also see three problems with that scenario. I have already mentioned the first two, which are that enterprises sometimes have more than one directory service, and that network administrators typically do not permit changes to the schema of a directory service to accommodate the specific data that application needs to have concerning its users. The third problem is the one that will actually be foremost in the minds of software vendors, which is that a lot of organizations, especially smaller ones, do not have any directory service at all, so having one’s application depend on a directory service that may not exist seems unwise.

The answer to our problems begins with a new Microsoft technology, called Active Directory/Application Mode, or ADAM for short. ADAM has the same external interfaces as Active Directory in that it is LDAP- and ADSI-compliant, and has a user interface that is a Microsoft Management Console snap-in. However, whereas Active Directory is the directory service for Windows 2000 and later domains, and can only be installed to serve in that capacity, on domain servers, ADAM can be installed on any Windows Server 2003 or Windows XP Professional machine. So, you might say that it is nothing more than an LDAP- and ADSI-compliant directory service, with a Microsoft Management Console user interface. I refer to ADAM as a technology rather than a product because it is free to download and redistribute. You can obtain ADAM from https://www.microsoft.com/downloads/details.aspx?FamilyId=9688F8B9-1034-4EF6-A3E5-2A2A57B5C8E4&displaylang=en.

ADAM is where the data for the users of your application belongs. I repeat: ADAM is where you should store data concerning the users of your application. We said that there were three obstacles to storing your user data in a directory service rather than in your application’s own database: first, that an organization might have multiple directory services; second, that network administrators resist modifications to enterprise directory services to accommodate application-specific user attributes; and, third, that an organization may have no directory service in which your application’s data can be stored. Well, ADAM takes care of the latter two of those three problems right away. Modifications to the schema of your application’s ADAM directory service will have no impact on the network administrator’s directory service, and if an organization adopting your application does not already have a directory service, well, your application does not presuppose that it does: it merely depends on its own ADAM directory service.

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Comments

• Anonymous
  March 04, 2004
  If the organization you are developing for does have a directory service, but you need to modify the schema. In those cases, I have relied on AD for authentication, and then additional attributes linking userIDs to permissions for authorization.
  
  Is there an easy way to keep an ADAM and a real AD synced?
• Anonymous
  March 04, 2004
  Ok, I just read your post about MIIS. Thanks.
• Anonymous
  March 04, 2004
  Application Security and Active Directory
• Anonymous
  July 29, 2004
  Application Security series finished