Application Security, Part 3

So, its 9 a.m: do you know where your users are? I’ll bet I do, because although we have just talked about where they should be, in the global directory service of the enterprise, I will wager that your user data is in your application’s own relational database. In my role, working with Microsoft’s software vendor partners, I have come across exactly one product that keeps its user data where it belongs, in a global directory service, and that vendor is Calgary-based Telvent, one of the largest and most successful software vendors in Canada that makes the supervisory control and data-acquisition software that is used to manage oil and gas and other pipelines. Everyone else is keeping the data for the users of their applications in their database.

Why? Well, the first reason is that programmers of business applications know how to use databases. Indeed, to them, databases are like crack cocaine: whatever’s the problem, the database is the fix. Directory services like Active Directory, on the other hand, are network administrators’ toys, so we are not nearly as familiar with them, and when it comes to thinking about where to keep our user data and access control information, well, we just put it in the database.

The second reason that user data ends up in the database rather than a global directory service is that some enterprises have actually ended up with global directory services, so they don’t have a single, central repository of user data for an application to rely upon. It is quite common to find one directory service that is used to handle network authentication and authorization, another directory service that is used by a PKI product for remote access through a virtual private network, a white pages directory service, and yet another directory service that supports extranet or Web single-sign on. It is also customary to find that these various directory services are based on different technologies. For example, an organization’s network authentication and authorization directory might be based on Active Directory, while the PKI directory is based on an X.500 directory, and the white pages and line-of-business directories are based on yet another directory technology.

A final reason that user data gets stored in databases rather than in a global directory service is that applications tend to need application-specific data about their users, and fields for storing that data may not exist in the schema of the directory services, and while one can modify those schemas, network administrators typically refuse to allow one to do that. Telvent often runs into that problem.

And so it is that although we may know that our user data and access control information really should not be in our application’s database but rather in the enterprise’s global directory, well, it ends up in the database anyway. So, is that really such a bad thing after all? Yes it is: it is a terrible state of affairs. Think of the implications. Every time a new application gets deployed in an enterprise, its database becomes yet another store of user data and access control information that gets added to an ever-growing collection of such repositories across the enterprise. Consequently, whenever a new person joins the organization, their information has to get added to all of the applications’ databases before they can use them, which requires effort on the part of the application administrators, and prevents the employee from being fully-productive as they wait to get access to their tools, which also means that the organization’s money is being wasted on that person’s salary as the person sits idle. The situation is even worse when a person leaves. Once again, the application administrators have to run around pulling the departing staff member’s data out of each application’s database, and there is a breach in the enterprise’s computer security for as long as the person remains an authorized user of an application after they left. And let’s face it: today, employee turnover is high, people are getting hired and fired all the time, so not having their data in just one place where they can be readily added or deleted is a more serious problem than ever.

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