OpenStack Identity (keystone)

Bug #968696
Comment #17

Comment 17 for bug 968696

Revision history for this message

Arvind Tiwari (arvind-tiwari) wrote on 2013-11-19:

#17

My suggestion to fix this issue

The biggest problem here is “roles name is global and keystone can no differentiate foo(Admin) vs bar(Admin)“ that is why Admin on a project become is admin on keystone resources (prject,users, group….) too.

This issue is mainly due to insufficiency of role data model which is nothing but just a name and there is no way we can define same role name for different services.

Solution:
======
1. Keystone should register itself in keystone along with other services and has given some name unique service_id. (e.g. keystone or identity=100 , NOVA=110 and Swift=120) (chicken and egg problem but can be done through system bootstrap)

2. Role definition should be scoped to a service_id, so that every service can create their own role.(e.g. Admin(100), Admin(110) and Admin(120)).

3. Role definition should have some info (may be a flag like for_non_project_use_only=true) to guide role assignment logic, so that certain role can/can’t be assigned to a project. (e.g. Admin(100,true), Admin(110,false) and Admin(120,false))

4. There should be validation in role assignment based on role definition’s for_non_project_use_only filed, so that non_project roles can’t be assigned to a project.

5. Based on scoping (domain/project) Token response should return role list with service_id (e.g. [Admin(110), Admin(120)])

6. Service scoped Auth (token) request should also be provided.

7. For any keystone API calls, internal user credential (which is used to validate against policy) should have role with service_id (e.g. [Admin(110), Admin(120)])

8. Keystone policy which considers role should also add “service_id” in policy (e.g. "identity:create_project": ["role:Admin and service_id:%(100)s"])
8.1 Note: target.service_id should be always 100 because we are operating on identity API, that means the target is controlled by identity(100) service.
8.2 For identity:create_project API call if user have “Admin(110)” (admin role scoped to a project) wd not satisfy "role:Admin and service_id:%(100)s" policy

My suggestion to fix this issue

This issue is mainly due to insufficiency of role data model which is nothing but just a name and there is no way we can define same role name for different services.

Solution:
====== 
1. Keystone should register itself in keystone along with other services and has given some name unique service_id. (e.g. keystone or identity=100 , NOVA=110 and Swift=120) (chicken and egg problem but can be done through system bootstrap)

2. Role definition should be scoped to a service_id, so that every service can create their own role.(e.g. Admin(100), Admin(110) and Admin(120)).

4. There should be validation in role assignment based on role definition’s for_non_project_use_only filed, so that non_project roles can’t be assigned to a project.

5. Based on scoping (domain/project) Token response should return role list with service_id (e.g. [Admin(110), Admin(120)])

6. Service scoped Auth (token) request should also be provided.

7. For any keystone API calls, internal user credential (which is used to validate against policy) should have role with service_id (e.g. [Admin(110), Admin(120)])

8. Keystone policy which considers role should also add “service_id” in policy (e.g. "identity:create_project": ["role:Admin and service_id:%(100)s"])
  8.1 Note: target.service_id should be always 100 because we are operating on identity API, that means the target is controlled by identity(100) service.
  8.2 For identity:create_project API call if user have “Admin(110)” (admin role scoped to a project) wd not satisfy "role:Admin and service_id:%(100)s" policy