Verify: feedback/fixes from Bryan addressed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Invalid
|
Wishlist
|
Dolph Mathews |
Bug Description
I'm glad to see section 2 begin by defining concepts. I'd suggest adding all these concepts to the openstack glossary at http://
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://
A general comment for section 5 is that for write operations the payload format should be discussed. Eg: when we PUT against /user/userId/
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/
Related branches
- Adam Bieńkowski (community): Approve (code / testing)
-
Diff: 19 lines (+1/-5)1 file modifiedsrc/PolkitDialog.vala (+1/-5)
Changed in keystone: | |
assignee: | nobody → Dolph Mathews (dolph) |
Changed in keystone: | |
importance: | High → Wishlist |
Changed in keystone: | |
status: | Confirmed → Invalid |
Rename and Fix Identity if possible.