Open Stack

On Jun 21, 2011, at 11:49 PM, Ziad Sawalha wrote:

Hi Bryan -

A general comment, which colors much of the thinking on Keystone, is that we are looking to have pluggable backends and protocols. We provide a sqlite implementation for reference and for ease of deployment, but it is not the intention for Keystone to be a comprehensive Identity Management solution.


On groups:
My understanding of the idea of a core API call is that it is implemented by all services. We're looking for Keystone to allow plugging in different back-ends (such as LDAP, PAM, Active Directory, or even simple, flat text files) and adding groups to the core APIs means all the backends will have to support them and map to the model we add. We don't want to force the model we have out there on all backends, so we'll take it out and let the best model win using the extension mechanism.

On tenant:
Your ITIL description is quite accurate, except that we're not extending the definition to include the authorization concern mentioned in ITIL. There may be other aspects to how a tenant is used (ex. Isolation of resources from neighbor effect in compute) that do not fit in that description. Let me attempt a modification to make it better describe what we have in mind for tenant in OpenStack:
"A tenant is a configuration within the service that holds configuration items for a specific "customer" of the service, where customer is defined by the operator and where the service provides the tenant identifier in relevant logs to allow per-tenant accounting (per http://wiki.openstack.org/openstack-accounting)."
Note: This is key. Thanks for the valuable input on this, Bryan. I'd like to include this in the docs when this conversation/thread ends…

On pagination:
Deferring to those spending many more hours on the APIs than I am. I will go by the spec as it evolves. This should probably be an OpenStack standard as opposed to a Keystone-specific behaviour (also included in docs like http://wiki.openstack.org/OpenStackAPI_1-1?action=AttachFile&do=get&target=c11-devguide-20110209.pdf and http://docs.openstack.org<http://docs.openstack.org/>/ ).

I agree that we can get away without exposing the URI structure.  Still it makes sense to expose the marker if only to ensure that implementors provide clients with a way in which they can iterate through the list in a stable manner. For the compute API we are considering requiring only next links -- and requiring that these lists reference a marker.


On PUT operations:
The identifier for users right now (username) is supplied in the payload, so it is a PUT. Same with groups.

On ATOM:
I agree with the principle, but the challenge will be picking up changes on a back-end store (like LDAP) and publishing ATOMs on those.

On clear text password and RFC2617:
Valid concern on clear text password. Can you elaborate on the bar you think we need to measure up against? RFC2617 is a pretty low bar…
Also, the 401 response that responds with WWW-Authenticate options is what we would expect would come back from the service (ex. Nova) and not necessarily from Keystone. Although Keystone may respond back with a list of protocols it supports. The idea of making the list of available protocols discoverable is logged here https://github.com/khussein/keystone/issues/31 .

On roleRef:
The fact that you ask reaffirms that we need to make them clearer. Wondering if if we're gaining RESTfulness at the expense of understandability here. I'll add an issue to track and follow up on this. (https://github.com/rackspace/keystone/issues/56)

On BaseURLs:
We renamed them to endpoints and endpoint-templates and will be updating the documentation soon. (https://github.com/rackspace/keystone/issues/57)



Bryan – thank you so much for your diligent review and solid feedback. I've added a ticket with most of the content of your email to make sure we address/incorporate all the items you raise. (https://github.com/rackspace/keystone/issues/58)

Regards,

Ziad



From: Bryan Taylor <btaylor at rackspace.com<mailto:btaylor at rackspace.com>>
Date: Mon, 20 Jun 2011 23:17:02 -0500
To: Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>>, "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal

I'm reading through the dev guide for the first time. I hope my comments are timely.

I'm glad to see section 2 begin by defining concepts. I'd suggest adding all these concepts to the openstack glossary at http://wiki.openstack.org/Glossary. The github site for keystone defines these concepts in the README, but also includes group, so I'd add that to section 2. I see groups and tenant groups are defined in the appendix as an extension. Why an extension? If an operator doesn't want to use them, can't they just ignore them?

The tenant concept is interesting. This may have been discussed elsewhere on this list, but I missed that conversation. I gather it's a somewhat flexible notion.  I've been immersed in ITIL lately, and it's language can help express this concept. Tell me if this is consistent with your idea of tenant: A tenant is a configuration within the service that holds configuration items for a specific "customer" of the service, where customer is a party with an independent right to assign users, groups, and roles to consume the capabilities of the service.

In example 3.1 the POST content type says it's a JSON request, but the POST'ed payload shows as XML. I'm a little concerned that the password appears to be sent in clear text.

In 3.3 we discuss paginated collections, and navigation via "next" and "previous" links, but you need to differentiate the limit and marker URI scheme for these cases. "next" links go to the page whose records are AFTER the marker, and "previous" links go to the page whose records are BEFORE the mark, so you can't use the same URI constructs for both. I  recommend ?after=lastID and ?before=firstID. There's also no reason to actually specify the URI structure in the spec . "next" and "previous" are enough.

In section 4.3 I wonder if there should be a notion of the authentication mechanism included, along the lines of RFC 2617's basic and digest authentication schemes. The RFC has a good treatment of various security issues in it's section 4. See http://tools.ietf.org/html/rfc2617 . I expect we'd be measured against this bar.

A general comment for section 5 is that for write operations the payload format should be discussed. Eg: when we PUT against /user/userId/enabled, exactly what does the payload look like.
In section 5.2.2, the first row shows using PUT against /users to create a user, but I expect you want POST here.

In 5.2.4 you PUT against /tenants to create a user, but I expect you want POST here, too. In 5.4 you discuss this as a POST.

In 5.2.6, we should describe what a roleRef is exactly.

I'm not sure why we cover tenants in both 5.2.4 and 5.4.  Similarly, we cover tokens in both 5.2.3 and 5.3.

In 5.5, we cover Base URLs. This should be covered in the concepts too, then.

In 6.1.2, we PUT to /groups to create a group, but I think we want POST here.

One thing that I would suggest adding that seems to come up a lot is a mechanism for tracking changes that will affect authorization logic or drive provisioning/deprovisioning activity. I suggest adding atom feeds of change events such as: user adds and deletes, revoked tokens, adds and deletes of users to roles, groups, and tenant groups. These atom feeds will allow authorization logic to be based on cached information that can be kept current within a desired latency by efficient polling of the atom feeds.


From: Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>>
Date: Fri, 10 Jun 2011 23:24:24 +0000
To: "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto: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


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110622/4e021a8c/attachment.html>