Every application has certain configuration information; most of the times; these configurations are hard-coded by their developers; but it’s a good idea to have that information in some external configurable place. We had been using INI files and Windows Registry to store that information; but then we have to hard-code the name and location of that INI file or the registry location. .config files were introduced with .NET along with the APIs to access them.
The problem with the above approach is management; especially when a single information is configured in multiple place; eg SMTP server address might be one piece of information but its configured in multiple applications; that all are using that particular SMTP server. SMTP server might not be a good example; as you can say; that information might not get changed over the year; but there are certain information that change more frequently; e-g connection strings, (database configuration and credential). In some nicely managed places; there might be a policy to change credentials after a fixed interval; even if its not the case; it might get changed whenever some employee leaves who knew that particular critical information.
Directory Services / Meta Data Services, comes to rescue us in such cases. They provide the central place to manage the information. Directory Services differ from Relational databases in a way; that Directory Services provides hierarchical information storage and they are usually optimized for quick searches and select operations and insert/update operations are not that optimized. Active Directory I guess is the most widely used Meta data service to manage authentication information within enterprises. Active Directory’s schema can be extended to store other pieces of information, and it provides ADSI provider as well as LDAP compatibility, which is an industry standard to access such information stores.
Active Directory has its overheads; like licensing, infrastructure costs and so forth; and for simple scenarios like the one I mentioned earlier; it might not be a good choice. There are certain alternatives like different open source and commercial LDAP servers that can be used. Recently, Microsoft introduced Active Directory Application Mode (ADAM) which is a light weight directory service and can be used on a standalone Windows system. It comes with nice GUIs for administration, well written documentation and the familiar APIs (ADSI, LDAP) can be used with it.
Next, I will try to post how I used ADAM to store connection strings at central place and Windows authentication to access that sensitive information from .NET apps.