Openstack Keystone is the Identity Management (IdM) gateway for the rest of the Openstack infrastructure.  While it is fairly new code, and not feature complete as of yet,  it does show some interesting aspects of cloud identity management and the issues it involves.  That, of course, begets the question of what is required in a cloud Identity Management gateway.

First of all,  lets look at what IPA manages:

1. Users
2. Hosts
3. Groupings of the above
4. DNS (Not just names for hosts,  but also Kerberos autodiscovery)
5. Policy (Sudo, HBAC. Policy, Directory Server Access)

The primary concept in Keystone not yet in IPA is Multitenancy. This can be thought of a form of Policy on top of groups.  I’ve started writing up the requirements.

Let me restate the definition of multitenancy:

Multitenancy is a policy of an identity management solution where a grouping segregates the visible of entities inside from those outside.

But not everyone will use FreeIPA,  and the Keystone target deployment is somewhat different from FreeIPA   Keystone in particular wants to be able to delegate back to the Tenant the management of their own set of resources in the cloud.

Hmmm… I think I can even convert that to a mission statement:

The mission of Openstack Keystone is to provide single sign-on for cloud management by delegating  IdM control of  the Tenancies to the Tenant Adminstrators.

I’ll leave that up there for a bit to see if someone can do me one better.

What do I mean by delegating to the tenant administrators.  I’ll give a couple examples.

1. If the user has FreeIPA or Active Directory in the home system,  they should be able to use them to Administer access to their own resources in the cloud
2. If a user becomes a reseller of Cloud services,  they should be able to manage nested tenancies for their clients

Here are some requirements of cloud IdM

1. A user who wishes to user the cloud providers IdM solution should be able to provide essential services and access control for users in their organization
2. A private cloud used to manage applications visile from outside the corporate firewall should be able to segregate  their customers, their suppliers, and their partners from each other, while maintaining an integrated  Identity Management Database.
3. Cloud IdM  needs to provide a cryptographically secure system that is at least as strong as that  provided by the users IdM systems.  While Kerberos is not necessarily an option across corporate firewalls due to blocked ports,  the IdM implemented by the Cloud provider has to be based on the same principals. The cloud IdM system must provide a reasonable degree o f trust both the the end user and the system administrator with regard to the identity of one another.

Comments?