Back in March, I wrote post called “Bring Your Own Identity” where I suggested that the next step in device management was to take these generic identity management tools (Facebook, Twitter, Google, Amazon) and allow users to log on with them inside the organization.

Bring Your Own Identity (BYOI) just arrived for business.

It is called “Identity”; it is Windows Azure Active Directory, and yes, it is from Microsoft.

Here’s why you might want to use it — how — and what.

The Backstory: The SaSS-y Company

Imagine a company that is 100% based on Software As A Service — or at least as close as we can reasonably come.  You have corporate email in gMail, collaboration in google docs and Google+, project management in LeanKitKanban (or maybe Pivotal Tracker), HR and sales using SalesForce.com, Accounting in Quickbooks online, PR using radianSix.  The desktop is just the device you use to get there; employees bring their own devices, use a Chromebook with no traditional operating system or a Mac.  Operating System doesn’t matter; everything is web-based.

It sounds wonderful, but the reality to that world is maintaining about a fifteen different logins.   One some of them, my email address will be my login; others will have a username.  Some will have requirements for a short password with a special character, others a longer without.  These tend to change over time, so I will end up with six or seven similar, but not identical, logins — I will likely write the logins and passwords on a piece of paper that I try to hide … and now we have a security problem.  Of course I can’t tie these to twitter or facebook because, if I leave the company, the company needs to own the data.  There’salso  no way I can tie these to active directory, because they are outside the firewall.

This is the void that Windows Azure Active Directory is trying to fill.  It exists outside the firewall, so you can use it as a login engine.  If the session is cached in the browser, you can “login with Azure” and save the typing step.  Configure the firewall with the right holes and certificates, and you can even have desktop login from Azure.  There are third-party solutions providers that can itegrate Azure with other systems for you, and good ol’ Centrify, that enables companies to achieve single sign-on with Active Directory to anything – linux, mac, mobile devices, Windows-Based SAP, ERP,and CRM systems, you name it.

We’ve got a lot of potential here, but I can’t help notice that there aren’t many success stories.  Device Management inside the firewall, or at least, single login (inside the firewall) has been around for years thanks to vendors like Centify.  Outside of it, we have things like the Federal Government’s Common  Access Card, that can inject login credentials into the browser — but not much in the private sector.  We could use LDAP, and, in some instances, Active Directory outside the firewall, if the vendor supports it, but those integration points are painful and slow.

The Identity AD, things will be less painful … if the vendor supports it.

I know. You’ve heard that one before.  We have a solid theory now; what we need are success stories.

I’m with you, and I’m looking for them.

More to come.

Do you remember Microsoft Passport?

The idea behind passport was a single web-based login.  You could use it for your Microsoft account, then surf on over to Amazon.com and you are logged; surf on over to eBay, or Hotmail, or Etsy, whatever, take your pick, and you remained logged-in.  Combine that with Microsoft Wallet, and you could purchase items direct to your credit card.

It was a great idea, to become part of Microsoft Hailstorm, a collection of web-based services.

Except that, oh yeah, right, it wasn’t.

Microsoft Hailstorm failed and was scrapped, almost exactly ten years ago.  You could argue, I think it’s worth taking seriously, that Hailstorm was ahead of it’s time, and the time actually is today.

Today all the building blocks are in place for an identity service, and it could directly impact your business.

Let me explain

Problems (And Solutions) with Hailstorm

The obvious reason that Hailstorm/Wallet/Passport failed was because Microsoft was unable to secure the partners it needed – the eBays and Amazons of the world were unwilling or unable to trust Microsoft with the login keys.  (For that matter, I suspect neither were the Mastercards or the Discovers.)  A second was the Hailstorm pushed a centralized services model — the applications existed “in the cloud”, and how they would interoperate with your personal devices was murkey.  Finally, in those days, integrating with one of these services was a “project” that probably a small team of people and a large amount of time.  Like the chicken and the egg, companies didn’t offer passport because it did not guarantee users, and users didn’t sign up because they couldn’t use it anywhere.

Facebook, on the other hand, hit 500 million users two years ago.

Beyond Facebook, there are several other popular options, including a Google Account, Twitter, or Linkedin.  On some “badge” or point-based sites, like StackExchange, I have lost track of which account to log in as, which means I have three accounts, each with about a third the points I should have.

It also means new website don’t need to build an authentication feature; they can re-use a code sample from one or two companies and be off to the races.  Instead of taking time, sharing authentication suddenly saves you time.

Back in the Enterprise

“Bring Your Own Device”, or BYOD, is getting a lot of press right now; there are entire conference tracks about it.  The gist of BYOD is that journalists got frustrated they could not get iPads, so they bought them for themselves and started using them for work — and started blogging and writing about it.

I’m only mostly kidding.  iPhones and iPads (and that other thing about a robot, and the one that’s a fruit) all can take time that used to be ‘lost’ to the business and make it productive.  It seems reasonable in my mind for people to take the systems they pay for out of pocket and volunteer to get company e-mail and, sometimes, some web services, on those devices.  IT will figure out how to support these folks; it won’t even take very long.

I’m not talking about BYOD here – I am talking about my identity.  Why do I need a separate login for work as I do for LinkedIn?  LinkedIn knows who I am.  They know where I work.  To some extent, it seems reasonable that the company have an interest in my LinkedIn account.  For example, I might make claims about what I do, or claim that I continue to work at the company after my employment ends.

Shouldn’t logging in to the company computer be as easy as logging in to LinkedIn?

It’s not that easy

Oh, I understand the objections.  There are privacy concerns – who owns the data and the login?  There are practical concerns; LinkedIn and Facebook are websites, and I need to authenticate to LDAP and Active Directory inside the firewall just to get to the machine.  Plus there are a pile of permission issues; who can modify what email list, who can FTP to what box, what group am I am a member of and what permissions does that group have on what machines — I get it.  We’ve got a long way to go.

But, for the moment, just hear me out.  What if we started to move our web architecture to make multiple, overlapping authentication schemes available, not just for public websites, but to streamline operations within our companies?

Repeat after me: The future is not Bring Your Own Device; that is the present.

The future is bring your own identity.

Tomorrow

Right now, today, I can stitch together external services I have described above.  I am not talking about that.

I am talking about internal services.

Say you hire a new administrator tomorrow at BigCo.  In Windows Seven and Eight land, he is stuck – he needs a security Wallah to create a user id, then needs to learn a new userid and password combination.

What if, instead, there was a “User my facebook login” button in Windows nine?  What if you configured the machine to allow the first person who clicked it to login, the create his LDAP account based on the user who logs in.  With today’s monitoring software, the risk is minimal, and you’d have to create all logins to external servers, FTP accounts, database, etc, just like the old way.

Again, there is no “login with facebook” feature in Windows 9.

Perhaps there should be.

]]> http://itknowledgeexchange.techtarget.com/unchartered-waters/bring-your-own-identity/feed/ 2