OpenStack Identity (Keystone)

Keystone Domains

Registered by Jason Rouault on 2011-09-16

Currently Keystone lacks the ability to scope users and their resources to an uber collection. Keystone is in need of a higher order entity (aka domain) to allow for the grouping of users, groups, roles, and tenants. A domain can represent an individual, company, or operator owned space. The intent of domain is to define the administrative boundaries for management of Keystone entities. By defining the domain collection an authorization system, whether external or internal to Keystone, can be used to enforce policies related to admin operations for that domain. With domains in place, administrative roles within each domain can then be defined to control CRUD operations on entities scoped to the domain. Additionally, domains afford the ability to setup cross domain trust relationships which can then be used to controlling the ability to give users one domain access to resources of another.

A sampling of related user stories:
1) As a cloud user I want to be able to create users who can have access to my tenants/services
2) As a cloud user I want to be able to control the kind of access that users have to my tenants/services by specifying role assignments for users.
3) As a cloud user I want to be able to create groups and place users into groups
4) As a cloud user I want to be able to control the kind of access that users have to my tenants/services by specifying role assignments for groups.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Medium
Drafter:
Jason Rouault
Direction:
Approved
Assignee:
Guang Yee
Definition:
Superseded
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
Joseph Heck on 2012-11-02

Related branches

Sprints

Whiteboard

ZNS: Domains to be added as an extension to the 2.0 API.

JLR: I still believe this should be core or part OS-KS admin extensions... This is a fundamental change to KS

JLR(11/29/11): If people feel that domains would be valuable, then HP will commit to put them into KS core. HP will not commit to implementing domains as an extension. As I stated earlier, the change is too fundamental to the entire data model for it to be an extension.

JFH(2/5/12): per discussion in last week's IRC (keystone-status) meeting, shifting this blueprint out to apply in the folsom-1 timeframe

Gerrit topic: https://review.openstack.org/#q,topic:bp/keystone-domains,n,z

Addressed by: https://review.openstack.org/8114
    blueprint keystone-domains

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.