Open Source projects usually get short shrift from pundits and journalists. Open source Identity projects get even less shrift.
(“Shrift”, by the way, has an interesting etymology, at least to those who wonder about where the words we use come from).
Commercial vendors have whole staffs of flacks (Public Relations/Media Relations/Analyst Relations specialists) whose sole job is to be sure that I and those like me are aware of everything that’s happening with their products. There are company CEOs, CTOs, sales and marketing execs, product managers and others who spend a good deal of their time getting out the message.
The Open Source Software (OSS) projects I’ve spent the most time talking about are those where the primary developer has reached out to me and spent time telling me about the project. Usually, there’s no one else to talk to. Sometimes a reader or client will point me towards an OSS offering that they’ve used to good advantage. Sometimes I’ll read about an OSS package (usually mentioned in passing) when seeing a comparison of offerings in a particular area.
All these is a lead up to telling you about a new source for finding OSS projects put together by my friend and neighbor Brad Tumy (he lives about 40 miles away from me – a trivial distance in the US). Brad posted Open Source Identity Solutions a week or so ago, so it really is up to date (at least concerning the projects he’s identified). They are divided into four groups: Provisioning/User Identity Management; SSO/Access Management; Federation; and Directory Services.
I often suggest that Open Source Identity Projects result from one person’s itch needing a way to be scratched. Once the “scratching” application has been developed, it’s released into the wild where others may or may not be willing to take it on and extend it. Generally, it’s of scant use to others unless they are willing to put in the time and effort to bend and twist the app to their needs.
Sometimes, though, the Open Source community can “hit the ground running” by, essentially, inheriting an already well developed product.
Looking at Brad’s list, one entry drew my attention – ForgeRock OpenAM, listed as both SSO and federation software (and noted as supporting SAML, OpenID and OAuth). Going to the OpenAM site, I was surprised to see that, this past spring, version 10 of the software was released. Surprised, that is, until I delved deeper into the package’s lineage.
ForgeRock OpenAM was previously called OpenSSO. As I noted back in 2005, OpenSSO was donated to the Open Source community by Sun Microsystems. In a detailed look at the transaction, my then colleague John Fontana (now an evangelist for Ping Identity) wrote: “The Open Web Single Sign-On project includes a subset of components from Sun's forthcoming Java Access Manager 7.0.” He went on to report that:
“The company's goal is to make the use of single sign-on and Web access management a given for corporate adopters and get them to focus on using that technology for a more complex project: identity federation, the sharing of authentication information across corporate boundaries.”
Seven years later, the project has matured – but corporate adopters are still reluctant to sign on. And not only to the OpenAM project, but to most SSO and federation projects.
In that 2005 column, I quoted security expert Bruce Schneier as saying “Passwords just don't work anymore. As computers have gotten faster, password guessing has gotten easier. Ever-more-complicated passwords are required to evade password-guessing software. At the same time, there's an upper limit to how complex a password users can be expected to remember." He could just as easily have said that last week. Passwords are the root of our data breach problems. Most of the breaches over the past couple of years have come about because the hackers involved have acquired – in one way or another – access to accounts that give them access to important data and they usually do this be stealing passwords, either through brute force attacks or some form of social engineering (with the latter becoming more and more preferable).
The obvious solution is to not even let users know their own passwords – what they don’t know they can’t reveal – by using a very secure SSO solution. My colleague Martin Kuppinger, however, maintains that the costs of creating a near-perfect SSO solution are holding back enterprises from doing so. And the need to re-educate users is being resisted by those very users. So multiple accounts with multiple passwords (or, worse, multiple instances of the same password) will be with us for the foreseeable future.
OpenAM solves, in one way, the cost factor. There is no cost for the software. There is, though, a cost in understanding the software. When you buy an application from a major vendor you usually get, at a minimum, configuration and installation support with a year or two of maintenance. For a price, you can get consultants to come in and do all the work. For a further price you can get 24x7x365 instant telephone access to knowledgeable support staffs to help with any problem that might come up. You don’t get this with Open Source software, for the most part. That really isn’t such a bad thing.
Buying the complete package of Access Management from a large vendor, complete with a raft of setup, configuration, installation and maintenance personnel saves you time. But when the support contract ends – and it will – you’re left with software that you really don’t understand, because you didn’t get your hands dirty setting it up and maintaining it.
With something like ForgeRock’s OpenAM, you do need to get under the covers and have an intimate relationship with the software. You need to learn everything there is to know about it, then implement it in a way that both works for your organization as well as keeps your organization secure. That isn’t an easy task, and it does come at a cost – in your and your organization’s time. You’ll need to have continuing training, also, because inevitably the person in your group with the most knowledge will find a way to leverage that knowledge to move along to an organization that will pay extra for that knowledge.
But, for those who know they need to move to better access control yet can’t convince the bean counters to budget the necessary funds for a commercial product, the price of entry for an Open Source solution can be the best answer.
All you need is a test bed of hardware, a little time squeezed out of your busy schedule and the Open Source package. You can quickly set up a demonstration project, show it to those in management you consider sympathetic, and find the backing for spending more time customizing the test installation to better reflect your organization. Move from success to success, gain more backing and – eventually – you’ll have the budget you need. Either a budget of limited funds and unlimited time, or vice versa. Yes, that Open Source “experiment” might not be what you end up with. It’s possible you might go all out on a splashy commercial project, perhaps because it has bells and whistles that are important to you and which aren’t in the Open Source solution – or would require you to develop further functionality with its own additional costs in people and development tools.
Still, if it gets you to a better, more secure, access management solution, then it’s well worth the effort. To help you evaluate the commercial offerings in the IAM area, you should check the list that another friend, Matt Flynn (from StealthBITS) has compiled and is – so far – keeping up to date.