The next conversation to be had

Ok, now that CIS and Catalyst conferences are (almost) out of the way, we need to rally the identity geeks and start talking about OAuth and OpenID Connect design patterns.   We need to get some public discourse going about token architectures for various real world business access scenarios.

The value proposition needs to be made more concrete.  So let’s try to push on that rope in the next few months.

 

Time to Act!

Did you know that a vote is on at the OpenID Foundation to approve an initial implementer’s draft of OpenID Connect?

Your action is required.

If you haven’t looked at these specs yet,  go to http://openid.net/connect.    If you have only limited time, check out the Basic Client Profile to get an idea of what we’re talking about, or look at Nat Sakimura’s OpenID Connect in a Nutshell.

If you don’t even know what I’m talking about,  you need to go find out.  OpenID Connect is an identity layer on top of OAuth 2.0.   It abandons the redirect-based structure of OpenID 2.0 completely, and instead embraces the API security layer.   While OAuth 2.0 takes care of the mechanism of asking for a token and using that token,  OpenID Connect creates a scope that protects a standardized set of identity services:  these services provide roughly the same set of attributes, authentication context, and session expiry information that you would get in a SAML assertion.

SAML, OAuth 2.0, and OpenID Connect, when taken together, allow identity and issuer/session information to become a known common quantity, traded either on the front channel or the back channel, consumable by the largest enterprises and the simplest mobile applications, and secured at any level of assurance.

If you are already an OpenID Foundation member, you simply need to visit a website, login with your openid, and cast your vote.  Go to https://openid.net/foundation/members/polls/62 to cast your vote.

If you aren’t an OpenID Foundation member, becoming a member is simple and affordable, you can join as an individual for USD $25.  Visit https://openid.net/foundation/members/registration to join, and then you too can cast a vote.

You only have 5 more days, voting closes on February 15th,  do not wait until the last minute!

Oracle Waveset

Acquisitions!  Can’t live with ’em, can’t wait until they stop holding up progress.   At least now we have new fodder for speculation.

What’s great about the Snoracle merger finalizing:  already I’ve seen more blogs from more people in “the know” who are reaching out than I can recall ever seeing from the Identity team at Oracle.   Nishant has always been the sole Oracle blogger in my acquaintance, but a few other voices are being heard – if you aren’t listening, you should be!  I am really excited about the idea that this merger could herald a cultural shift at Oracle towards more transparency.

The dust has settled on the initial announcements, and the big surprise is that OIM (previously Thor) has been chosen as the strategic provisioning product.  I can see all sorts of technical reasons why this might be the case – I imagine that the original Thor product had already been heavily retooled for integration into the fusion middleware suite.  Any other strategic considerations (size of existing customer base, ease of expansion, etc) really don’t have as much weight as those of us on the outside had been assigning for a simple reason:  the Waveset customer base is captive. There is no competitor right on the heels of either OIM or Waveset, no hungry beast to prey on dissatisfaction or fear around assimilation costs or adapter growth/expansion for Waveset.  As such, Oracle can play it cool by supporting Waveset long enough to appease nervous customers, cherrypick the functionality that is missing from OIM, and eventually find a migration path once the dust has settled.

So then, we have the following communities:  1) Existing OIM customers, who are relieved I’m sure. 2) Existing Waveset customers, who are probably unimpressed, but who will hopefully be well supported and given a migration path. 3) New customers, who are in the worst position, having had their choices narrowed. Will prospective customers keep asking for “Oracle Waveset” (the re-rebranded name of Sun Identity Manager)?  Or will memories fade fast?  There is a hole now – will another product fortuitously step in, for example Forefront Identity Manager 2009 2010?

I also wonder what kind of pressure SaaS will put on applications that traditionally are provisioning hard cases.  If you are an software vendor competing against SaaS services, and that SaaS service offers a provisioning API that allows for a 10-minute integration into an automated Enterprise infrastructure, wouldn’t you be worried? Will bricks & mortar software companies feel compelled to compete?   I hope and pray that this will be the case – and frankly I can’t figure out why on earth any software vendor would prefer to have a provisioning tool bypass its core logic and reach into the backend database to twiddle bits.

The access front is interesting, if not surprising.  Given that OpenSSO was opensourced, I don’t think anyone really felt it was likely to replace OAM, but in this case there is a migration path that sees customers stay with the pre-Oracle codebase and maintain the code themselves (I hear there are integrators out there already offering up a new neck to choke with respect to codebase management and support).  Oracle has said that there are a few things that they will adopt from OpenSSO, but I imagine that the opensourcyness of OpenSSO might be a barrier there, most engineers I know are loathe to mix license types in a product.

No matter what happens, at least it’s now able to happen openly.  As Green Day sings:  “every new beginning comes from some other beginning’s end“.  The world marches on, but I’ll always remember the long hours I spent in the Sparc 1 and Sparc 2 labs at university; on Sparc 5’s and 20’s at the beginning of my career; and the time spent on the ever-renamed directory that started at Netscape, went to iPlanet, then SunOne, then suffered from all sorts of horrible marketing mangling around “Java” and “Enterprise”.  The pre-marketing-mangled Sun brands will always make me smile; they were representative of a bright shiny world that I felt awed to be a part of.

“Kick Me” for Cloud

Patrick just posted to the Ping CTO blog some of our combined thoughts about what a  terrible idea it is to synchronize Enterprise passwords to the cloud:  Grounding Enterprise Passwords.Kick Me, Please

The ctotalk blog post is much more detailed so make sure to read it, but let me sum up in somewhat stronger terms:  Giving away the shared secret that (for better or worse) is often the key to your internal windows domain and to anything linked into that domain is a really stupid idea.   It is the IT equivalent of putting a “Kick Me” sign on your organization’s back.   It means that no matter how stringent your own security regime is, you are only as secure as the weakest of the partners you synchronize to. Most partners are loyal and upstanding, employ good people and protect your passwords better than you do, but even then,  if/when you get hacked,  who are you going to point fingers at?

I believe Enterprises should be educating their employees NEVER to set or use an Enterprise password outside of the Enterprise.  I also believe that a cloud service is nuts to actually accept passwords synchronized from their customers.  Of course it goes without saying that the better choice is to eliminate external passwords altogether, but if you can’t do that, at least try to keep users from typing the same set of credentials into every web form that comes their way, while protecting your partners from even the implication that they might sell your password list.

Massive Step forward

As of very recently, I have had the pleasure of working on contract for Ping Identity – and I have been dying for today, because I can finally talk about what the combination of PingConnect and Google can accomplish.

Traditionally, the ability to integrate a disparate set of cloud applications for a userbase was predicated on the non-trivial task of first creating a Start of Authority.   As a bare minimum, you had to (a) create an authoritative user repository and (b) enable some kind of service to perform an initial authentication and leverage the resulting session to facilitate federation to various parts of the cloud.  After that, you still had to figure out who could consume what you had worked so hard to be able to establish.

Now, you can make Google your Start of Authority, and instantly get to a laundry list of 60 applications with PingConnect.  All without a Windows domain, a WAM server, or a federation server, and best of all, by utilizing an existing repository that is likely to be maintained regularly.  AND, there is actually useful stuff to get to.   This may not sound like a big deal to the companies who all have Windows domains anyway, but I believe that this could push back the need for a growing small business to get a Windows domain quite significantly.  To me, the start of authority problem was a massive barrier to adoption for federation, and that barrier has been obliterated, not just on the cost front but on the effort front too.  They say it takes a village?  Well now we actually have one worth hanging out in.

Interesting times.

Dear Enterprise Application Vendors:

I believe we’ve hit a crossroads, my friends. Here’s what’s happening. We have a groundswell of support and interest in technologies that reduce the need for passwords in the Enterprise. Some of these technologies have been around awhile. Some of them are new. All of them want to integrate with YOU, the Enterprise Application. Action is necessary in the immediate future.

In talking to your fellow vendors, I can almost feel the panic – you can’t possibly support all of the new technologies coming out, you aren’t even supporting technologies that are years old — how do you choose?

My advice is not to put money into one-off integrations — but instead to work to abstract the authentication/identification details from your core application code altogether. Now is the time to make those architectural changes, and to do so as a result of strategic vision rather than a frenzied response to a line item in a critical customer RFP.

No matter what technology rises or falls, flexibility in authentication methods will become a key differentiator in the next 5-10 years for Enterprise applications. Prior to this, the applications have pre-existed and SSO projects have attempted at great expense to integrate what is already there. I believe that in the next few years, the tables will turn. Cost of Enterprise Identity & Access Management integration will be factored into Enterprise Application business cases.

My preference? Set up your application so that the customers can write their own identity front-end integrations. Allow your client base to directly underwrite & collaborate on support for the technologies that they need.

I think the trend is clear here — whether it is user-centric identity, 2-factor authentication, federation, or classic SSO– something (and maybe many things) will supplant the login forms and isolated proprietary communication of identity data that happens today. You can surf that wave, or you can let it pound you into the sand… which will it be?

For those of you in the IT industry — if you agree, be VOCAL. We all know that the squeaky wheel gets the grease. If you want flexibility in identity integration for your Enterprise, you have to ask for it, ask early, ask often, and ask LOUDLY…