Open Stack

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.


  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.

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

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