Open Stack

Hi David/Kirtsy,

So a few questions:

- How do the attribute sets get created (e.g. roles, projects, domains)?  Are you assuming that as these are created in keystone they are replicated into the attribute service?  Or that these are created independently somehow? Or maybe crated on-the-fly as relationship requests come in?
- What api (that other projects can use) actually populates the mapping service with the group-project-role and group-domain-role relationships (remember there are no "tenants" in v3)?  Is this front-end api the one I defined in the user-groups blueprint, but that the backend relationships for groups are then stored in the attribute service? Or are you thinking that the other projects will call the mapping service to define those relationships?  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)?

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
>> 
>> 
>