openstack team mailing list archive

["Rouault, Jason (Cloud Services)" <jason.rouault@xxxxxx>]

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] On
Behalf Of Ziad Sawalha
Sent: Thursday, July 21, 2011 12:52 PM
To: 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-registratio
n).
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-supp
ort).

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>
Date: Fri, 10 Jun 2011 18:24:21 -0500
To: "openstack@xxxxxxxxxxxxxxxxxxx" <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/identityde
vguide.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/identityd
evguide.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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature