Open Stack

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