Archive for March, 2010

IAM in the cloud?

Thursday, March 18th, 2010

Seems like everyone is talking about moving everything to “the cloud” these days.

Increasingly, the conversation is turning to moving IAM systems from an internally hosted platform (i.e., on a physical or virtual server) within the corporate perimeter, to an externally hosted platform, run by a service provider and connected over the public Internet.

I wonder if there’s value to be had by doing this, or if it’s just the usual industry “buzz” – fickle and pointless. I rather suspect the latter.

Don’t get me wrong – I get the value proposition of moving some applications out of the perimeter and onto a cloud vendor’s network, where they get installed, configured, maintained and upgraded by specialized, skilled professionals. There are all sorts of advantages to moving apps out of the perimeter and onto a “cloud” vendor’s network:

  • No physical hardware to buy, install, power, cool and maintain.
  • No software to install and manage.
  • Someone who really understands the application in question manages it for you, instead of someone on your internal IT team who has to manage 10 different apps and is an expert with none of them.

I just don’t get that every conceivable type of application belongs outside the perimeter. Consider some counter-arguments:

  • The corporate perimeter is still very much firewalled.
  • Firewalls are porous in one direction (outbound) and usually quite tightly closed in the other direction (inbound).
  • A user provisioning, password management or other IAM application designed to manage users, identity attributes, passwords and entitlements spends much of its time connecting to your existing applications, in order to create and delete accounts, manage group memberships, read and write identity attributes, set passwords and so on.
  • If the IAM system is outside your perimeter, then it will have to “reach into” your network to do all that stuff:
    • That’s a security problem – lots of holes have to be opened in your firewall.
    • Do you really want privileged credentials for your core systems stored on a database that belongs to another company? I didn’t think so.
    • That’s a performance problem – do you really think it will get the same sort of bandwidth going across the continent as it will going 10 feet from one server rack to another, at your own data center?

So long as you still have a significant set of applications installed inside your perimeter, your IAM system should stay on the inside.

On the other hand, if all your apps are outside (and by the way, where did your corporate directory go?), sure, move the IAM system out too.

Look at it this way — your internal IAM system is probably the last one you should move out of your perimeter. Right before you turn the lights off on your proprietary data center.

Does that mean there is no use case for “IAM in the cloud”?

Not really. There are still lots of reasonable use cases.

For example, you might be managing users and passwords on other apps which themselves have been moved out into the cloud. For example, do your users sign into WebEx? Google Apps? Why not use your (still internal) IAM system to manage those? It’s really no different than managing users and passwords on your internal AD or SAP systems.

What about federation? You can certainly leverage user authentication inside your network to eliminate secondary logins to applications outside your network.

You can even go the other way – let your partners’ users sign into their own corporate directories and click right into your partner-facing apps in your DMZ.

That’s all well and good. But it doesn’t argue for relocating your core IAM function (you know, user provisioning, password synchronization/reset, etc.) out of your network’s perimeter.