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]<mailto:[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

Reply via email to