Hi, Looking at your posts openstack/keystone<https://github.com/openstack/keystone>at GitHub seems to be the recommended version for Diablo, however Launchpad points to this version <https://launchpad.net/keystone/diablo>, so I'm a bit confused about which is the Diablo version for Keystone. Any hint about this?
Bye. 2011/9/21 Dolph Mathews <[email protected]> > ** > I believe this review satisfies the remaining requirements that keystone > was lacking: > > https://review.openstack.org/#change,516 > > See the new functional test in keystone/test/functional/test_auth.py: > test_user_auth_with_role_on_tenant(), which illustrates the flow you > outlined. > > At the moment, the only issue preventing a merge appears to be that the > LDAP-backend implementation is failing to return GET /tenants properly. Any > help here would be appreciated, as I'm sure someone else is more familiar > with LDAP than I. > > -Dolph > > > On 09/21/2011 03:16 AM, Jesse Andrews 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > This email may include confidential information. If you received it in > error, please delete it. > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
