Open Stack

Hi

So a few additional comments in-line below.  

Further, I'd like to (re-)suggest my original proposal that we submit a reference implementation for groups as defined in the blueprint (in fact the client side api for this is already up for review at: https://review.openstack.org/#/c/17693/).  The server side would be available for review this week - this is relatively straight forward given the existing rather nice design of the v3 support in general (kudos to whoever did that, btw).  The advantage of this approach is that

a) We are guaranteed a solution for Grizzly
b) As components of the attribute mapping service come into play, we integrate them in to the exiting flow and remove redundant parts of the reference implementation
c) We can decide fairly late how pervasive the attribute support for organizational roles  is - e.g. - if it front-ended by a more traditional simple groups api?  Or an attribute api, with a simpler "groups" ui, or the full thing, etc.    

This would give us a lot of flexibility - e.g. we could decide, for instance, that in Grizzly, we'll use the attribute mapper to store the group relationship, but actually present it as a traditional group capability on the front end (i.e. give us more time to come up with a suitable api/ui for generalized attribute mapping...maybe with a preview in Grizzly)...and then expose the (already stored in AM) underlying relationships directly in H.   Or some other combination of hybrid implementation that lets us strike that right balance for the state of the s/w in a couple of months.

Adam/Dolph - any views/comments?

Henry
On 7 Dec 2012, at 15:05, David Chadwick wrote:

> Hi Henry
> 
> On 07/12/2012 14:24, Henry Nash wrote:
>> Hi David/Kirtsy,
>> 
>> So a few questions:
>> 
>> - How do the attribute sets get created (e.g. roles, projects,
>> domains)?
> 
> In the first version the Keystone admin will create them via a new user command. We dont think the backend storage will need altering as we are simply creating a new type of object to be stored there. (An organisation admin could also create new mappings but it would be uncontrolled access). In the second version organisational admins will create the mappings and access controls will ensure they can only set their own attributes to authorised roles. So we can have multiple administrators updating different mappings in a controlled manner in the second version.
> 
So in terms of customer experience, I think you are saying that if a cloud provider wants to offer organizational roles to their customers, then there is a manual set up required by the Keystone admin to create these sets...these, I assume, are in addition to the user/roles/metadata tables (or whichever backend solution is bring used) that  will exist already?  We'll need to come up with a way of sharing the names/Ids of these"well known"  sets - since keystone will need to name them in the api calls to pick up the mappings.
> 
> Are you assuming that as these are created in keystone
>> they are replicated into the attribute service?
> 
> No, they are stored in Keystone's backend storage and the AM reads then from there. So they are only stored once.
> 
> Or that these are
>> created independently somehow? Or maybe crated on-the-fly as
>> relationship requests come in?
> 
> Yes to both. Independently created by admin during initial configuration of Keystone. Then they will also be created on the fly in the federated Keystone when new users appear. The way this will work is as follows
> i) the mapping that the admin puts in says this attribute type (but no value specified) maps into a tenant/project with no value specified. ie. it is a rule for creating new tenants for each new identified user who has a specific set of attributes. (the same can apply for roles, although that sort of defeats the whole purpose of RBAC if each user has his own role. However it could be done at the organisation level e.g. set up a mapping for org attribute to role, then every new organisation would create a new role for itself and every user from the organisation would get the new role)
> 
> ii) When a federated user first uses Keystone, the federated module will find that no specific mapping exists for him so it will create a new tenant and or role and add a new mapping for this user to this tenant/role using the AM.
> 
> 
> - What api (that other projects can
>> use) actually populates the mapping service with the
>> group-project-role and group-domain-role relationships
> 
> Kristy has already specified the API internally. She should publish it over the weekend or on Monday.
> 
> (remember
>> there are no "tenants" in v3)?
> 
> Tenants are projects arent they? So doesnt v3 have projects? If so we can simply substitute tenant for project.
> 
Yes there are projects, but projects are not the only thing that can have roles assigned to - so can Domains.  Large enterprise customers will  probably treat the domain as the "account holder" or tenant, not the projects that come and go. So in this scenario we need to allow organizational roles to be assigned to a domain or a project (and hence and user who has that organizational attribute then gets the respective role on that object)
> Is this front-end api the one I
>> defined in the user-groups blueprint,
> 
> Not sure we will need to check this out
> 
> but that the backend
>> relationships for groups are then stored in the attribute service?
> 
> the AM does not store anything itself. It relies on Keystone's existing storage mechanism to store the objects. What the AM does is define some new objects and populate the Keystone storage with them. So we have defined add, read and delete operations on these objects.
> 
> 
> Or
>> are you thinking that the other projects will call the mapping
>> service to define those relationships?
> 
> In principle any administrator can use the AM API to create mappings, but in order to activate and control this, we will need a proper access control mechanism with delegation of authority from the Keystone administrator to the AM administrators. This delegation might be by the keystone admin creating access rules himself for these other AM administrators e.g. by creating some new admin roles and then assigning these roles to the other AM administrators. Precise details are still to be worked out for this.
> 
> 
> 
>  If the later, have we defined
>> this api (in terms of what actual http calls we support and the
>> client side python to make it easy for these to called)?
> 
> that's good. So Kristy should compare your APIs with her APIs and see what the similarities and differences are. Can I leave it to the two of you to agree what these APIs should be. Essentially we need get, post and delete
> 
Sure.  More than this, however, have we thought about what an example UI would be for this - we will need that in Horizon.  We want people to have organziational roles out of the box.  This might be challenging - we need to come up with a generalized UI concept for attribute mapping (I assume there must be examples of this already, however), that is simple enough not to confuse the users who just want "groups" when there are in, what is for now, the usual case of a non-federated world, but is extensible enough not to require re-design if they ever go federated.
> regards
> 
> David
> 
>> 
>> Henry On 6 Dec 2012, at 13:46, David Chadwick wrote:
>> 
>>> Hi Henry
>>> 
>>> I discussed this very topic with Dolph in London yesterday. This is
>>> what we agreed would be the most sensible implementation route
>>> (Dolph please correct me if I am wrong)
>>> 
>>> 1. Henry writes code that can add group memberships to the user
>>> identity store (maybe backend LDAP or whatever). Each user will
>>> probably have a group member attribute added to his entry, but
>>> details are for Henry to decide, since he will be responsible for
>>> both storing and picking up the groups. This will probably involve
>>> changes to Keystone client, but may not require any changes to the
>>> backend storage, depending upon how flexible it is (e.g. Kristy has
>>> managed to add IDPs to the service catalog without making any
>>> changes to the service catalog or backend storage)
>>> 
>>> 2. Henry writes a new Keystone middleware module for the pipeline
>>> that, after the user has been identified and authenticated, calls
>>> the identity store to pick up the user's groups (added in 1 above).
>>> It then calls Kristy's Attribute Mapping Service, passing it the
>>> groups and getting back the tenants and roles. It then hands back
>>> control to the Keystone pipeline.
>>> 
>>> regards
>>> 
>>> David
>>> 
>>> 
>>> On 06/12/2012 11:43, Henry Nash wrote:
>>>> David/Kristy,
>>>> 
>>>> So let's try and move this discussion on so that we at least have
>>>> a clearer description of what we would implement on both paths -
>>>> and make progress towards getting code into Grizzly.
>>>> 
>>>> The traditional implementation (as defined by the bp:
>>>> https://blueprints.launchpad.net/keystone/+spec/user-groups )
>>>> would involve: - Api implementation to support semantics
>>>> described (e.g. in keystone client) - A GroupControllerV3 in
>>>> keystone to pick up and dispatch these calls to the backends (e.g
>>>> sql, kvs), as well as a few changes to other controllers affected
>>>> (e.g. RoleController) - Backend implementations to support the
>>>> semantics - e.g. in sql the addition of a group,
>>>> GroupProjectMetadata and GroupDomainMetadata tables, mirroring
>>>> the way we do user-project/domain-role assignment - Tests at the
>>>> various levels against all these
>>>> 
>>>> Now I *think* what you are suggesting is that, if we were instead
>>>> to use attributes to achieve group membership, that the code in
>>>> the Controllers would instead make calls to the attribute mapping
>>>> service for group membership aspects.  It isn't really a new
>>>> backend (since you aren't supporting everything as attributes),
>>>> but conceptually something similar.  Do I have that right?  Or do
>>>> you see the changes as more pervasive?
>>>> 
>>>> Given that I am implementing this starting from the front end
>>>> (e.g. create the api support fist and all the tests should all
>>>> fail with not implemented), then the controllers, and then
>>>> backends...this might interlock with a little more time to make a
>>>> decision on where the backend is implemented.  Given the rather
>>>> nice clean way that the new controllers/backends are implemented
>>>> - even doing a reference implementation in the traditional
>>>> fashion, then swapping out (or modifying) the controllers to talk
>>>> to the attribute mappings service might be a good way of
>>>> progressing this.
>>>> 
>>>> Henry
>>>> 
>>>> 
>>> 
>> 
>