Open Stack

All good, Jesse.

I think it would be appropriate to either create a new smoketest that
stresses the flow you outline below, or add a new integration test to
here:

https://github.com/sorenh/openstack-integration-tests

Otherwise, testing will by nature be a manual process....

Cheers!
-jay

On Wed, Sep 21, 2011 at 4:16 AM, Jesse Andrews <anotherjesse at gmail.com> wrote:
> 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 :)
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>