Partager via

Application Security, Part 3

  • Article

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.]

Comments

  • Anonymous
    February 23, 2004
    I can partially agree with you but why every different application must be authentificated by their own database?
    It's all about common authentification data schema.If it's relational or some other kind-dosen't matter.
    One big problem with directory services that it dosen't support native xml interfaces(though implies hierarchical structure), I'm not talking about DSML-it's simply transport protocol.
    In present time Yukon with help of XML schemas+XQuery(WinFS Contacts anyone? ;-) is much more powerful/flexible/easy to use/standard than any directory service(Oracle with XML DB think about it also).

    It was several posts(on weblogs.asp.net) about why UDDI at all and that it was born dead from begining.
    It seems same situation here, in big "solid" corporations directories have their place but small "distributed" world prefer something more simple/flexible(WS-Adressing/discovery etc.),and this approach wins as practice reveals(remember SGML to XML transition?)

    Thanks,nice article.

  • Anonymous
    March 04, 2004
    Application Security and Active Directory

  • Anonymous
    July 29, 2004
    Application Security series finished

  • Anonymous
    March 16, 2008
    PingBack from http://bordercrossingstatsblog.info/craig-mcmurtrys-weblog-application-security-part-3/

  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=craig-mcmurtry-s-weblog-application-security-part-3

  • Anonymous
    June 18, 2009
    PingBack from http://firepitidea.info/story.php?id=761