What happened to Directory Services?
OATH, OAUTH, OpenID - this is all getting too complicated. We need simple identification for the future.
The reason it caught my attention was not because I agree with him (I do), but because the idea of simple authentication, especially among disparate systems, has been the Holy Grail of IT, and every time we think we have it solved, the solution seems to fall apart in our hands. In fact, OpenID/OAUTH/OATH is only the most recent attempt at solving the authentication problem. The last attempt was a little standard called X.500, and Jan's tweet this morning reminded me, not only of x.500 and its promises, but how far the standard has failed, because of its complexity.
I have not really thought about Directory Services lately because I have been in so many shops where it has been so badly implemented (or not) that it is almost not worth thinking about, even though millions of users use it, or rather its baby brother, LDAP, every single day, most notably in the form of Active Directory, but also Novell Directory Services, Oracle Directory Services, Fedora Directory Services and other LDAP systems, too numerous to mention, most depending on some form of the OpenLDAP project.
But Directory Services were, themselves, an attempt to solve the user virus problem of large, disparate, interconnected networks where tools like NIS and NIS+ were functionally running out of gas, while providing access to other, more secure authentication features as this thing we call the Internet was really beginning to take off. The X.500 standards were designed to make it easier to interconnect systems using a standard lookup mechanism. It was, of course, a hideous disaster, as anyone who has had to work with a pure X.500-based system can tell you, at least from a functional standpoint, but from a theoretical standpoint, it was the right direction.
In the 1990s, companies like Oracle and Novell both posited that there needed to be some form of interconnected directory service that would facilitate the ability to prove you were who you were without having to register with each and every web site and system that you needed to connect to, whether you were on your private intranet or the public Internet. And like simple authentication, the idea of single sign on has been a snipe most of us have spent our careers chasing.
For example, I worked at an organization where Microsoft's Active Directory was the law of the land. It controlled everything from how your desktop looked and performed (if you were running Windows of course) to how you accessed your email, to how you accessed the VPN. But when you connected to the education and training system, you had to have a completely different set of credentials. And since most people only connected to the system yearly for those mandatory sessions we all have to take in the corporate world, there would be a huge flush of trouble tickets at the beginning of the year for password resets (the system did not have an automated password reset system either - that was for security reasons...yeah, yeah, I know, I did not design the system, I just had to use it, but I digress). The point here is that when the system was being designed, there were discussions about how to integrate authentication with the Active Directory structure and the powers at large decided that it would be a bad idea to do that. This was not some antique mainframe that could not be connected without a Herculean effort, this was a simple web site, running on Microsoft software.
If you use LDAP, you know how much of a challenge it can be to not only set up, but integrate and manage. Creating a usable LDIF file is almost an arcane science (and a hold over from the X.500 days), and integrating LDAP authentication with some systems is easier than with others. It has gotten better than in the early part of the century, but it is still not as easy or as seamless as we would like it to be, especially when you are going across platforms to some that are less LDAP aware or even support a different implementation of LDAP.
Several years ago, I actually signed up for an OpenID. Between then and now, something in the OpenID standard must have changed, because my OpenID credentials from then no longer work now, which really defeats the purpose.
The point here, though, is that in 2010 we are still looking for a method to connect to systems without having to register with all of them. And with all our current solutions, we still have not quite got that problem solved. And if someone mentions web of trust I might scream. Because, after all, that is the root of the problem, or at least one of them.
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide
- Bruce Nikkel's Practical Forensic Imaging (No Starch Press)
- Transitioning to Python 3
- Progress on Privacy
- Stepping into Science
- Linux Journal December 2016
- Radio Free Linux
- CORSAIR's Carbide Air 740
- The Tiny Internet Project, Part II
- FutureVault Inc.'s FutureVault
- A Better Raspberry Pi Streaming Solution