Identity in Openstack Icehouse

Editor's Notes

• #5: OpenStack tenants are referred to as projects
• #8: A diagram representing IaaS, PaaS, and SaaS. Applications may be leveraging a cloud platform, or be using the infrastructure directly
• #9: The tradeoff as you get higher level of abstractions is that you gain simplicity and are put on track for higher scalability, but lose control. By using open source tools, organizations can regain some of that control
• #10: There are three cloud environments - private, on premise clouds, externally hosted clouds run on dedicated hardware for the customer, and public clouds like EC2 or Rackspace Cloud where you are using a portion of the infrastructure and being billed based on usage. Enterprise solutions like VMWare are attempting to move into the market on the right, while OpenStack is attempting to move left
• #11: Openstack has Compute, Network, and Storage resources. Across all these components, you have the Dashboard which provides management UI, and the Identity layer which provides authentication for all the components
• #13: It is important to realize that configuration of infrastructure may have different identity needs and be a different authentication domain than the compute resources on top, and that the operating system being virtualized may still have different needs than end user content. Keystone targets the needs of the IaaS administration specifically
• #14: Keystone operates as a facade against existing systems. You may put all the information into an LDAP, although it is perhaps more typical to set up a SQL database to store information in an enterprise environment, rather than give Keystone write access. You may also set up keystone to operate from just a SQL database. For authentication, you can perform password authentication, or can use authentication functionality implemented by a fronting proxy for Kerberos and X.509 client certificate authentication.
• #15: At its core, keystone is about authenticating users and issuing tokens to be used for API calls. These tokens would be reusable if captured, so they must be sent over a secured transport. Tokens are scoped to a project or to a domain. Projects can share security settings in keystone via a local concept called domains. Two models are supported for tokens - a UUID reference to the user information, and PKI-based token which contains the information locally. There is no refresh mechanism for tokens, so while they have a limited lifetime, this is usually set to be at least 24 hours.
• #16: At its core, keystone is about authenticating users and issuing tokens to be used for API calls. These tokens would be reusable if captured, so they must be sent over a secured transport. Tokens are scoped to a project or to a domain. Projects can share security settings in keystone via a local concept called domains. Two models are supported for tokens - a UUID reference to the user information, and PKI-based token which contains the information locally. There is no refresh mechanism for tokens, so while they have a limited lifetime, this is usually set to be at least 24 hours.
• #18: The tokens issued always contain a user and role assignments. They almost always contain a scope limiting them to operate either at the level of a particular domain, or a particular project. Finally, they may contain extra metadata from the authentication system.
• #19: API Requests to the various services in Openstack in pass a token in the header of a request. The service has a policy which it received from keystone, which contains rules that it uses to evaluate whether the request is authorized. If access is authorized, the service performs whatever action is appropriate for the API and returns a response. As this flow is so common, keystone provides both clients and server filters for openstack projects as well as third party clients and components.
• #20: OpenStack has a new release every six months with alphabetically increasing names. For the most recent Icehouse release, SAML functionality was added by leveraging the Shibboleth project. Shibboleth’s Apache-based service provider acts as a filter on authentication requests. This provides SAML Web SSO and ECP profile support for acquiring tokens. However, this is only meant for gaining an API token. There is not yet support for having the Dashboard component, which provides administrator-facing web configuration UI, to authenticate the administrator via SAML.
• #21: Federation is exciting because it simplifies the concept of a hybrid cloud. With universal access to standardized API to configure domains, you may write tools that would set up infrastructure in remote environments the same way you would do so locally. Components can move from one cloud to another, infrastructure can scale from the internal environment to third party providers based on load, and organizations can make decisions to share compute resources that are often under provisioned in a tit-for-tat arrangement.
• #23: So whats coming? Nothing is set in stone, but there are efforts underway to enable some very useful functionality, some of which may land in the Juno timeframe: Today, you have a single identity system for your whole OpenStack installation. Going forward, you will be able to have different identity systems for different domains. While there currently is not browser SSO into the administrative dashboard, there are already efforts to extend the current SAML support to cover this. Likewise, the OpenID Connect protocol is completed and provides several interesting features, especially to organizations which haven’t already committed to using SAML. There have been experiments to support this protocol as well.