[Openstack] OpenStack Identity: Keystone API Proposal

andi abes andi.abes at gmail.com
Thu Jul 14 03:22:32 UTC 2011


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.sawalha at 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.rouault at hp.com>
> Date: Thu, 16 Jun 2011 19:54:22 +0000
> To: andi abes <andi.abes at gmail.com>
> Cc: Ziad Sawalha <ziad.sawalha at rackspace.com>, "
> openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
> Subject: RE: [Openstack] OpenStack Identity: Keystone API Proposal
>
>   See inline…****
>
> ** **
>
> Jason****
>
> ** **
>
> *From:* andi abes [mailto:andi.abes at gmail.com <andi.abes at gmail.com>]
> *Sent:* Wednesday, June 15, 2011 5:04 PM
> *To:* Rouault, Jason (Cloud Services)
> *Cc:* Ziad Sawalha; openstack at 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.rouault at 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.abes at gmail.com]
> *Sent:* Wednesday, June 15, 2011 9:18 AM
> *To:* Rouault, Jason (Cloud Services)
> *Cc:* Ziad Sawalha; openstack at 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.rouault at 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.com at lists.launchpad.net[mailto:
> openstack-bounces+jason.rouault=hp.com at lists.launchpad.net] *On Behalf Of
> *Ziad Sawalha
> *Sent:* Friday, June 10, 2011 5:24 PM
> *To:* openstack at 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 abuse at rackspace.com, and delete the original message.****
>
> Your cooperation is appreciated.****
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110713/413792e3/attachment.html>


More information about the Openstack mailing list