I think the exchange unscoped to scoped is not working for me, I think the issue may come from
GET : *http://192.168.1.48:5001/v2.0/tenants* ---START TEST--- POST : *http://192.168.1.48:5001/v2.0/tokens* {"auth":{"passwordCredentials":{"username":"admin","password":"secrete"}}} RES : {"access": {"token": {"expires": "2011-09-27T15:16:31.015850", "id": "8b523cbc-4805-49f5-bfd2-520e67f3bd81",* "tenant": {"id": "1", "name": "admin"}}*, "serviceCatalog": [{"endpoints": [{"adminURL": " http://192.168.1.48:5001/v2.0";, "region": "RegionOne", "internalURL": " http://192.168.1.48:5000/v2.0";, "publicURL": "http://192.168.1.48:5000/v2.0"}], "type": "identity-service", "name": "keystone"}], "user": {"id": "2", "roles": [{"id": "1", "name": "Admin"}], "name": "admin"}}} GET : *http://192.168.1.48:5001/v2.0/tenants* RES: {"tenants": {"values": [{"enabled": true, "description": "None", "name": "demo", "id": "2"}, {"enabled": true, "description": "None", "name": "admin", "id": "1"}], "links": []}} If I select the admin tenant the exchange works fine: POST : *http://192.168.1.48:5001/v2.0/tokens* {"auth":{"tokenId":"8b523cbc-4805-49f5-bfd2-520e67f3bd81","tenantId":1}} RES: {"access": {"token": {"expires": "2011-09-27T15:16:31.015850", "id": "8b523cbc-4805-49f5-bfd2-520e67f3bd81", "tenant": {"id": "1", "name": "admin"}}, "serviceCatalog": [{"endpoints": [{"adminURL": " http://192.168.1.48:5001/v2.0";, "region": "RegionOne", "internalURL": " http://192.168.1.48:5000/v2.0";, "publicURL": "http://192.168.1.48:5000/v2.0"}], "type": "identity-service", "name": "keystone"}], "user": {"id": "2", "roles": [{"id": "1", "name": "Admin"}], "name": "admin"}}} POST :* http://192.168.1.48:5001/v2.0/tokens* {"auth":{"tokenId":"8b523cbc-4805-49f5-bfd2-520e67f3bd81","tenantId":2}} RES : {"unauthorized": {"message": "Unauthorized on this tenant", "code": "401"}} ---END TEST--- BTW, I can't add more than one user to a tenant using the REST API (any clue?) 2011/9/26 Rafael Durán Castañeda <[email protected]> > 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
