openstack team mailing list archive

[Jesse Andrews <anotherjesse@xxxxxxxxx>]

As part of the release meeting today we talked about getting a preview release of keystone + dash + diablo working asap.  This is an attempt to summarize the major interfaces.  Ziad and team have an identity guide (they are updating and can share asap) to help flush this out.

Here is what I see needs implemented to make Dash + Nova + Keystone work together.  This is a subset of the auth spec (what Ziad & team are working to support Diablo as these are the contracts between those services)

1. CREATE TOKEN: (enduser api)        POST /v2.0/tokens
    post data: https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/auth_credentials.json
    response: https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/auth.json

2. VALIDATE TOKEN: (admin api)         GET /v2.0/tokens/(token)?[belongs_to=(tenant_id)]
    response: https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/validatetoken.json

3. TENANTS FOR TOKEN: (user api)    GET /v2.0/tenants
     returns: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/docbkx/samples/tenants.json

These 3 APIs are the meat of the keystone auth api (disregarding CRUD operations for users/tenants)

Flow:

* user visits a web console to login to openstack
* dashboard uses keystone to authenticate (dashboard has no internal user system, and shouldn't store username/password in session/shared state)
* since there can be a many to many relationship between users and tenants, the user might need to specify the tenant they want to operate on before talking with services like nova/glance/...
* A service like NOVA need to validate (via http proxy or middleware) the token and return a USER, TENANT (previously known as a project in nova), and a list of roles.

Notes:

* a tenant is a "project" in nova and an "account" in swift.  Think of it as the entity that "owns" the resources.
* a user is the acting entity.
* while keystone implements many-to-many tenant/user support, services should support many-to-many, one-to-many, one-to-one - as the API makes no assumptions about the hierarchical nature of the users/tenants
* when getting the response to the "create unscoped token", I write that it returns "stuff".  While it technically returns the roles, serviceCatalog, userinfo (same structure as for the scoped token), it isn't guaranteed to be the complete list of roles/endpoints for every tenant the user is a member of.
* since the goal of the dashboard is to toggle visibility/functionality based on capabilities presented in the service catalog, we ask for a scoped token that has the capabilities for the tenant / user pair.
* I use nova as my example but the approach is generalized.
* crud operations for users/tenants exists both in "keystone-manage" and api calls.  While dashboard has had user management capabilities in the past, we might rely on command line user management for the first release of the preview.
* mistakes in this summary are mine (please correct me)…  up until a few hours ago I had assumed the relationship betweens tenants/users and tokens was subtly different.

ps. The swimlane (sequence diagram) was generated with sdedit (sourceforge) and is attached for patches :)

Attachment: keystone.sdx
Description: Binary data