Open Stack

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 <rafadurancastaneda at gmail.com>

> 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 <dolph.mathews at rackspace.com>
>
>> **
>> 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     : openstack at lists.launchpad.net
>> 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     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110926/59b86a23/attachment.html>