Identity and Access Management or IAM is crucial as organizations move into the cloud. IAM allows an organization to centrally create, control and track individual identities, defining how users must first authenticate so that decisions can be made about what they are authorized to do.
Typical corporations or government agencies use cloud products from multiple providers, making federated identity management necessary. “Federated” is the same concept as in governmental theory, high-level organization above a group of semi-independent states. Or, in this case, clouds.
The result is a form of single sign-on. Within your organization, you sign in once to obtain your Kerberos tickets and those give your session access to file servers, databases in various departments, secured web servers, and so on. All of those Kerberized services are within the same realm, and so they agree on the authority of your Kerberos server for user authentication, authorization, and cryptographic key management.
But how could this happen in the cloud, where your organization and all of your cloud providers are entirely separate organizations?
The point of Active Directory Federation Service is to extend your Active Directory control into the cloud.
More sophisticated approaches use SAML or Security Assertion Markup Language to communicate authentication and authorization information between security domains. Those domains would include your organization, your cloud-based identity provider, and your cloud-based service providers. Ping Identity and Symplified were early players in this field.
The idea is that your in-house identity provisioner will define a user to an identity provider like CA CloudMinder. This includes a specification of how that user must authenticate, and then what authorizations are granted if the authentication is successful.
The user then tries to access a corporate resource. We don’t care whether either the user, the resource or both are in-house or “out in the cloud.” The corporate server asks the identity provider via SAML “Please authenticate this user.” Authentication handshaking meeting your requirements take place between the user and the identity provider. The user’s session gets a virtual token and the identity provider communicates the results via SAML back to your server. The user’s connection is then directed to the requested resource.
So why my worry about Facebook?
There are some people talking seriously about using Facebook identities for corporate identity management!
That’s right, Facebook, the place for your easily constructed personal and supposedly corporate identities to share “likes”, links to funny videos, and drunken party pictures, all in an environment of low security and not even an attempt at privacy.
But Facebook is free, it’s easy to use, and users (and more management than will openly admit it) will welcome an excuse to give them access to Facebook to, uh, support crucial corporate operations.
We discuss IAM in Learning Tree’s Cloud Security Essentials course, but we don’t suggest that you simply let Facebook handle it! The danger of relying on Facebook is possibly even worse than it appears. Check back next week for ominous news about the protocol on which Facebook authentication relies.