This session will include the following subject(s):
SAML, OAuth 2, and SCIM - Overview and Application:
A discussion of how identity standards may apply to keystone, and how keystone may wish to align itself with these standards through Havana and beyond.
A brief tour will be given to level set the room on the following current and approaching standards. It is recommended that anyone wishing to participate in the discussion read the attached links for background information in order to prepare.
- SAML An XML-based identity assertions commonly used for cross-domain single sign-on (A.K.A Federation) for Web SSO and Web Services (WS-*). IETF drafts describe use with OAuth 2.0.
Executive Overview: http://bit.ly/16Hn35X
- OAuth 2 - token based authentication for web applications and APIs. Defines the client software as a role. Separates issuing tokens from how you use a token. Token issuance is defined both for browsers and for REST clients using a username/password. Token format is not defined by OAuth2, but one proposed standard format is JWT.
OAuth2 Simplified: http://bit.ly/14aaH6U
- JWT - JSON Web Tokens, an upcoming standard format for structured tokens (containing data) which are integrity protected and optionally encrypted.
JWT spec: http://bit.ly/15YAKMx
- SCIM - cross-domain user account creation and management. REST API for CRUD operations around user accounts
We already support some mechanisms for plugging in authentication methods, but we need to evolve the keystone architecture to enable deployers and cloud providers to use their chosen set of authn/authz. This is not just about plugging things into the back of keystone, but needs to take into account how tokens might be validated (e.g. we do PKI today, but how would we cleanly enable some other standard token format?)
Goals for session: - Agree proposal for how we split the authentication & authorization in terms of API, laying the groundwork for us to expand the supported set of technologies - Agree how alternative authn/z and their token generation fits into the above structure - Agree where and how plugin points will be provided for such alternatives, including within auth_token middleware - Show an example proposal for OAuth (Authorization)with OpenID Connect (Authentication) that match the above.
This session will include the following subject(s):
Scaling/Performance of Keystone:
A number of recent reports have indicated that we have potential scaling and performance issues with Keystone. Examples: 1) Sequential execution when hit by a large batch of requests (200 x create user) 2) Inefficient use of SQL for individual requests (e.g. we don't use PK access for filtering by a PK variable)
The solution is likely multi-fold: a) Should Keystone use the same multi-process wsgi approach as other projects? b) Re-evaluation of the backend drivers to enable most efficient use of SQL/LDAP
(Session proposed by Henry Nash)
Thursday April 18, 2013 11:00am - 11:40am PDT
B114
A large deployment has a single Keystone endpoint serving multiple regions, each with multiple availability zones.
A user wishes to get a list of regions in a deployment. This is currently not possible.
A user wishes to get a list of availability zones in each region in a deployment. This also is currently not possible.
A user wishes to use novaclient (or any of the openstack clients besides keystone) to operate against availability zone 2 in region A of a deployment. The user would like to be able to specify --os-availability-zone on the command line like they do when specifying --os-region-name on the command line and have novaclient negotiate to the correct availability zone's compute endpoint automatically, in much the same way as is currently done if there is only a single endpoint for compute returned in the service catalog part of the authentication response.
Unfortunately, this, too, is currently not possible. The user must know ahead of time which compute endpoint URI to supply to novaclient for availability zone 2 in region A and pass that URI to novaclient with the --uri CLI option.
Just because this is how Amazon Web Services requires one to target compute or volume operations against different availability zones does not mean this is either user-friendly or good design -- it probably has more to do with the homegrown way that Amazon Web Services grew up than any architectural design the AWS developers made.
The natural place for information about a deployment's regions and availability zones is Keystone. It is NOT Nova, since availability zones and regions affect all services, not just compute.
I'd like to discuss adding support for region and availability zone CRUD to the v3 or v4 API of Keystone.
(Session proposed by Jay Pipes)
Thursday April 18, 2013 11:50am - 12:30pm PDT
B114
OpenStack services such as Cinder are offering encryption for volumes, an off-shoot implementation for Swift exists, Glance is a logical next candidate. Encryption involves keys, their creation, access control, and secure maintenance. Several blueprints touch on it. Let us design and develop a high availability solution. Perhaps a sub-service of Keystone (on par with Identity). With PKI tokens and X509 certificates in OpenStack now, the encryption keys could be encoded before being saved, for example, a volume encryption key would be "owned" by Cinder, so it could be encoded using Cinder's public-key. //key//. Would it be useful to have a reference count associated with keys, when all objects associated with it deleted, the key may be deleted. Support key caching on the services to reduce chattiness with Keystone.
This session will include the following subject(s):
Keystone LDAP Integration for Enterprises:
In this proposal we present use cases for how Keystone needs to integrate with an enterprise's existing LDAP infrastructure. We have identified the following as valid use cases for which Keystone should be extended to ensure a seamless integration with existing LDAP environments:
1. A Keystone LDAP integration model whereby Keystone is integrating with a read-only LDAP and leveraging the contents of this LDAP for both authenticating users and also for authorization (e.g. project, roles, etc).
2. A Keystone LDAP integration model whereby Keystone is integrating into multiple LDAPs such that it utilizes a read-only LDAP for authenticating users and then leverages a separate read/write LDAP for performing authorization.
3. A Keystone LDAP integration model whereby Keystone is integrating into multiple LDAPs such that it utilizes a read-only LDAP for authenticating users and group information and then leverages a separate read/write LDAP for accessing projects and role information
4. A Keystone LDAP integration model whereby Keystone is integrating into multiple LDAPs such that it utilizes a read-only LDAP for authenticating users and then leverages a separate read/write SQL backend for performing authorization.
5. A Keystone LDAP integration model whereby a separate LDAP or SQL backend can be chosen for authentication/authorization for each domain and mechanism are in place to prevent leakage of sensitive data from one domain to another. Note: This topic will be covered in more detail in http://summit.openstack.org/cfp/edit/158.
6.Multiple Keystone Active Directory integration models that are similar to the ones listed above except integration is with Active Directory instead of other implementations of LDAP.
In this session our expectation is to discuss these use cases, receive feedback, and identify other use cases during the session as well.
The quota situation is getting out of control. There are already a number of quota implementations for Swift. I expect that Glance will get its own implementation of quotas next followed closely by Quantum and probably Cinder. Each service will have its own implementation and different API to boot. This is definitely suboptimal.
We need centralized quotas, otherwise it will become an operations nightmare.
This session will be focused on how that goal can be achieved and who would be willing and able to contribute to it.
I've started an Etherpad at https://etherpad.openstack.org/HavanaCentralizedQuotas for this session and to track the existing efforts on quotas. Feel free to add any implementations I've missed.
To keep the session focused we won't be discussing Nova quotas. If we can nail down a way forward for centralized quotas, perhaps one day we can roll Nova quotas into it.
Currently Keystone returns all endpoints in the service catalog, regardless whether user have access to them or not. This is neither necessary nor efficient. We need to establish project-endpoints relationship so we can effectively assign endpoints to a given project, and be able to filter endpoints returned in the service catalog based on the token scope. Furthermore, we need to be able to optionally ask for service catalog on token validation instead of always returning them.
In a large implementation, there can be many users each having some level of access to a shared pool of resources. Not all users need that much access though and there are cases where access must be restricted further. V3 introduces policies and that works for restricting access to certain capabilities (only a user with the role "admin" or group "foo" can create server in nova, etc). Policies bloat up though if they need to get down the resource level (only joe can delete server "ABC").
This session is to discuss possible solutions to provide fine-grained access control to OpenStack services