openstack team mailing list archive

[Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx>]

We've trimmed down the API significantly and decoupled it from the reference implementation we have. That means that behavior can now be determined by the implementation or deployment. As long as the contract is adhered to, the way the roles and tenants are returned can vary. Here are two examples:

1. In the case of Rackspace, for example, we'll return a token that gives you access to a the tenants you own.
2. In the use case documented in the code repo under docs/design, the token returned does not have access to any tenants by default and a call to GET /tenants is used to get a list of tenants available.

That means the following in answering your questions:
>> Are all possible Service Endpoints returned after authentication based upon the users relationship to various tenants via roles?
Not necessarily. All endpoints that you get access to by default (as determined by the provider) are returned. A further call to GET /tenants could return additional tenants you could access by making a scoped authentication call.

>> When the Auth Component validates the token, are all possible roles and Groups across tenants for that user returned?
All roles (no groups, we've moved those out to an extension for now) that that token provides access to should be returned. However, the spec does not dictate that these roles be fixed or even stored in the backend. This allows for someone implementing a Keystone-compatible API endpoint on top of a system which dynamically evaluates and returns a list of roles based on the credentials provided (or maybe even the time of day they were presented).

Z

From: "Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx<mailto:jason.rouault@xxxxxx>>
Date: Thu, 21 Jul 2011 19:53:14 +0000
To: Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx<mailto:ziad.sawalha@xxxxxxxxxxxxx>>, "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: RE: OpenStack Identity: Keystone API Proposal

Ziad,

What is the expected behavior when requesting and using an unscoped token?  Are all possible Service Endpoints returned after authentication based upon the users relationship to various tenants via roles?  When the Auth Component validates the token, are all possible roles and Groups across tenants for that user returned?

Thanks,

Jason

From: openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx<mailto:openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx> [mailto:openstack-bounces+jason.rouault=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ziad Sawalha
Sent: Thursday, July 21, 2011 12:52 PM
To: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal

Hot, Texas summer regards to all!

Since my last note we have had much progress on Keystone. Particularly:

  *   We now have Nova, Dashboard, Glance, and Keystone integration (https://github.com/cloudbuilders/deploy.sh
  *   We've done some work on Swift integration (https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift_auth.py)
  *   LDAP an be your backend (https://github.com/rackspace/keystone/pull/102)
  *   We're incubating! Keystone is now officially an OpenStack Incubation project.
  *   And many other updates, enhanced testing, stability improvements, etc…
In my last note I called out our latest API proposal and asked for input. We've received much of that input – thank you - and have four new blueprints to change the API. These are:

  1.  Support Service Registration (blueprint here https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration).
  2.  Remove support for 'default' tenant. Instead, a 'Member' or 'default' role can be used to manage a default tenant (this may be implemented in the legacy_token_auth front end (blueprint here: https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant).
  3.  Support for EC2 API and non-password credentials (blueprint here: https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials).
  4.  Support for API versioning in the service catalog (blueprint here: https://blueprints.launchpad.net/keystone/+spec/service-catalog-version-support).
I'd like to invite comments on those blueprints (here, by email, or on the whiteboards or on the keystone issues list on github. Use the medium you prefer). As well as any new blueprint proposals to change the API.

I'd also like to propose a date for locking down the 2.0 API for Diablo. We're going to need some time to finish the implementation by feature freeze (Sept 10th), so I'd like to open the debate up for about three weeks and propose we lock down the API by the end of the weekend of August 14th.

Give us your requirements… and let me know if the dates don't work for you or your projects/teams.

Best,

Ziad


From: Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx<mailto:ziad.sawalha@xxxxxxxxxxxxx>>
Date: Fri, 10 Jun 2011 18:24:21 -0500
To: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: OpenStack Identity: Keystone API Proposal

Time flies! It's June 10th already. In my last email to this community I had proposed today as the day to lock down the Keystone API so we can finalize implementation by Diablo-D2 (June 30th).

We've been working on this feverishly over the past couple of weeks and have just pushed out a proposed API here: https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf

For any and all interested, the original source and code is on Github (https://github.com/rackspace/keystone<https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf>), along with the current implementation of Keystone, examples, sample data, tests, instructions, and all the goodies we could muster to put together. The project also lives on Launchpad at http://launchpad.net/keystone.

The API we just put out there is still a proposal. We're going to be focusing on the implementation, but would still love to get community input, feedback, and participation.

Have a great weekend and regards to all,

Ziad




This email may include confidential information. If you received it in error, please delete it.
This email may include confidential information. If you received it in error, please delete it.