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:[email protected]] Sent: Wednesday, June 15, 2011 9:18 AM To: Rouault, Jason (Cloud Services) Cc: Ziad Sawalha; [email protected] 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) <[email protected]> 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: [email protected] [mailto:openstack-bounces+jason.rouault <mailto:openstack-bounces%2Bjason.rouault> [email protected]] On Behalf Of Ziad Sawalha Sent: Friday, June 10, 2011 5:24 PM To: [email protected] 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 [email protected], and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
