Dropped off the thread for a while... sorry. Ziad, I think this sounds very reasonable. I think the only hiccup might be with the use of the term "role" which might connote some "bigger" meaning to folks with AAAA backgrounds.
If I understand your proposal, then a service can decide what is the granularity of ""thingies"" it registers with keystone(sorry.. no better term comes to mind - it's what you refer to in #2). These thingies can be "roles" or "actions" or whatever makes sense to the authorizing middleware. In Jason's model, these thingies can be in the form of: <service-namespace>:<object-type>:<action>. In this case, it could be convenient to have a keystone api to check if a given thingy is bestowed on a user, rather than returning the full list of thingies the user possess. The rational here is that if services do end up defining very granular thingies (please do come up with a better name...) then the list might get somewhat lengthy. On some systems I've worked on we had 100's of action-tokens (more or less the name we used) - returning the full list, even filtered by the service's name-space, might be a bit much. On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha <ziad.sawa...@rackspace.com>wrote: > Here's a possible use case we can implement to address this: > > 1. A service 'registers' itself with Keystone and reserves a name (Ex. > Swift, or nova). Keystone will guarantee uniqueness. > 2. Registered services can then create roles for the service (Ex. > swift:admin or nova:netadmin) or tuples as suggested below > (nova:delete:volume) > 3. On token validation, Keystone returns these roles and a service can > apply it's own policies based on them. > > This is super-simplified and we can expand on it. > > Other benefits: > > - Registration would also be handy to allow services to add and manage > endpoints as well. > - We can also tie this with the concept of a ClientID so services can > identify themselves as well with a long-lived token (see > https://github.com/rackspace/keystone/issues/84) > - Common names for services could be implemented as shareable among > different implementations (Ex: compute:admin) > > Thoughts? > > And comments inline ZNS>> > > > From: "Rouault, Jason (Cloud Services)" <jason.roua...@hp.com> > Date: Thu, 16 Jun 2011 19:54:22 +0000 > To: andi abes <andi.a...@gmail.com> > Cc: Ziad Sawalha <ziad.sawa...@rackspace.com>, " > openstack@lists.launchpad.net" <openstack@lists.launchpad.net> > Subject: RE: [Openstack] OpenStack Identity: Keystone API Proposal > > See inline…**** > > ** ** > > Jason**** > > ** ** > > *From:* andi abes [mailto:andi.a...@gmail.com <andi.a...@gmail.com>] > *Sent:* Wednesday, June 15, 2011 5:04 PM > *To:* Rouault, Jason (Cloud Services) > *Cc:* Ziad Sawalha; openstack@lists.launchpad.net > *Subject:* 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. > JLR>> I think there are a number of ways to account for this if we > leveraged a hierarchical (URI) structure and allowed for wild carding. *** > * > > ZNS>> We start to get in the world of policies here (lookup XACML) > > 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 **** > > JLR>> Please explain the model for Tenant, Accounts, Projects, Groups, > Roles…. I have not been able to discern how tenant will map to accounts and > projects. In any case, there are things that can be done to improve the > potential overhead of authorization calls… however, you will not eliminate > it completely. That is the price you pay for increased security. If > authorization is pluggable, operators can determine if and how they want to > use it.**** > > ZNS>>tenants are the same as account in swift and project in Nova. The term > tenant is not as overloaded as account, so we chose it. > > 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**** > > ** ** > > JLR>> Each service would need to document its target structure and actions > (this would be very similar to their published API’s). I think there would > be a default set of roles and permissions pre-populated to satisfy the base > set of use cases. **** > > **ZNS>>Maybe there are some built-in or reserved ones for Keystone and/or > OpenStack (Ex keystone:admin and compute:admin). I'd suggest they were > configurable if we did do that… but would help simplify a fast install and > canonical deployment of OpenStack.** > > 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. ** > ** > > > JLR>> Without a pluggable authorization system, operators will never be > able to provide fine-grained access control without mucking with hardcoding > in the API layer. That is not a good path**** > > >>ZNS: Indeed. A slippery slope. We want to provide core functionality out > of the box, but we don't want to end up writing a complete IDM solution… > > 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 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**** > > **** > > **** > > **** > > **** > > **** > > 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**** > > **** > > ** ** > This email may include confidential information. If you received it > in error, please delete it. >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
