Re: [Openstack] OpenStack Identity: Keystone API Proposal
Is there a plan to also have Keystone be the centralizing framework around authorization? Right now it looks like policy enforcement is left to the API layer. Thanks, Jason From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: Friday, June 10, 2011 5:24 PM To: openstack@lists.launchpad.net Subject: [Openstack] 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 Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Identity: Keystone API Proposal
I would expect that the API of each service would have to interpret the role assigned to a user in the context of that service - roles for swift nova glance quantum etc would probably carry very different semantics. So, to my understanding, key stone provides authentication and user information - what tenants the user has access to, and what roles the user is assigned. The mapping of these to what the user can do on what instances in each service are left for the service to determine. On Wed, Jun 15, 2011 at 10:32 AM, Rouault, Jason (Cloud Services) jason.roua...@hp.com wrote: Is there a plan to also have Keystone be the centralizing framework around authorization? Right now it looks like policy enforcement is left to the API layer. Thanks, Jason *From:* openstack-bounces+jason.rouault=hp@lists.launchpad.net[mailto: openstack-bounces+jason.rouault=hp@lists.launchpad.net] *On Behalf Of *Ziad Sawalha *Sent:* Friday, June 10, 2011 5:24 PM *To:* openstack@lists.launchpad.net *Subject:* [Openstack] 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/keystonehttps://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 Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Identity: Keystone API Proposal
Jason, Sounds like the model you're proposing could be achieved by something like this: On Keystone: - Roles are identified by name and contain tuples in the form of: -- the service to which this permission applies (e.g. service nova, swift). Including the service is meant to side track attempts to normalize actions across very different types of services -- the type of target this action applies to - e.g. volume, network port etc. -- action this permission allows - e.g. start vm, create volume. - An authorize API call which accepts: - the service requesting the authorization - user token (from a previous authentication) - tenant ID (to resolve the realm of the user token) - a target type - the attempted action. This API would lookup the token, and if its present combine a set of the relevant permissions from all the roles the token is referencing. If the requested tuple exists in this combine set, the request is authorized. A few caveats remain: a) the above description doesn't include Resource Groups... as Ziad mentioned, that is currently differed. When those are introduced, the service should probably pass the instance-id of the target, and Keystone would have to take that into account. b) the current API's in keystone allows a service to perform actions on multiple instances across tenants (containers) efficiently - a service could obtain a list of accessible tenants and cache it. If only the 'authorize' API is available, the service would need to perform a check with keystone for every instance c) In this model it is required to populate role definitions into keystone, for all services. Since keystone should be independent of other services, the set of actions/targets should probably be considered as data for it - requiring a deployment step of sorts to make keystone aware of these roles. This could be avoided if the authorization decision is looked at as 2 separate steps: 1. figure out what roles a user posses. 2. expand the set of roles to set of actions allowed 3. determine if the action attempted is allowed it is obviously debatable where keystone ends and the services begin. In the model above, keystone is responsible for all 3 steps via the authorize API. I *think* the current API provides a very similar model, with the line drawn at 1 - i.e. keystone provides to roles, and there is a separate middleware piece to perform 2 3, executing in the request pipleline of the service. Where this middleware executes (i.e. what is the API boundary to keystone) doesn't necessarily change the overall model. I *think*. On Wed, Jun 15, 2011 at 11:52 AM, Rouault, Jason (Cloud Services) jason.roua...@hp.com wrote: In my opinion the services (and their developers) should not need to interpret roles thus resulting in varying semantics. Roles should be defined by a set of configurable privileges to perform certain *actions*on specific *targets* for particular *services*. The API should only need to know to check with an authorization subsystem whether the incoming request is allowed based on the who is making the request and the 3-tuple mentioned previously. Jason *From:* andi abes [mailto:andi.a...@gmail.com] *Sent:* Wednesday, June 15, 2011 9:18 AM *To:* Rouault, Jason (Cloud Services) *Cc:* Ziad Sawalha; openstack@lists.launchpad.net *Subject:* Re: [Openstack] OpenStack Identity: Keystone API Proposal I would expect that the API of each service would have to interpret the role assigned to a user in the context of that service - roles for swift nova glance quantum etc would probably carry very different semantics. So, to my understanding, key stone provides authentication and user information - what tenants the user has access to, and what roles the user is assigned. The mapping of these to what the user can do on what instances in each service are left for the service to determine. On Wed, Jun 15, 2011 at 10:32 AM, Rouault, Jason (Cloud Services) jason.roua...@hp.com wrote: Is there a plan to also have Keystone be the centralizing framework around authorization? Right now it looks like policy enforcement is left to the API layer. Thanks, Jason *From:* openstack-bounces+jason.rouault=hp@lists.launchpad.net[mailto: openstack-bounces+jason.rouault=hp@lists.launchpad.net] *On Behalf Of *Ziad Sawalha *Sent:* Friday, June 10, 2011 5:24 PM *To:* openstack@lists.launchpad.net *Subject:* [Openstack] 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
[Openstack] Floating IP in OS API
Hi OS developers. Let me present the full specification (http://wiki.openstack.org/os_api_floating_ip) for the blueprint (https://blueprints.launchpad.net/nova/+spec/openstack-api-floating-ips) Any response from the community about the spec is very important for us. -- Eldar Skype: eldar.nugaev ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
