Jump to: navigation, search

Difference between revisions of "Horizon/DomainSupport"

m (An new admin domain should be created)
(Next Steps)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Domain Support (Work In Progress) ==
+
== (Work In Progress) ==
  
 
=== Use Cases ===
 
=== Use Cases ===
Line 10: Line 10:
  
 
==== An new admin domain should be created ====
 
==== An new admin domain should be created ====
  - Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.
+
  Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.
  
==== Project Admin should be avoided ====  
+
==== Project Admin ====  
  Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains
+
  Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains.
 +
Project Admin is restricted to quota mgmt and listing roles, role_assignments by the current keystone v3 policy file.
 +
Project Admin can not currently manage the members of it's project due to permissions for list_users.
  
 
==== Domain Admins and Project Admins should be mutually exclusive. ====
 
==== Domain Admins and Project Admins should be mutually exclusive. ====
  - Domain Admin + Project Admin is not recommended  
+
  Domain Admin + Project Admin is not recommended
  - Domain Admin + Project Member is not recommended
+
 
 +
==== Only Cloud Admin(s) should have a role on an admin domain ====
 +
  Non-Cloud Admin users should not have a role on the default admin domain
  
 
=== Definitions ===
 
=== Definitions ===
Line 38: Line 42:
 
  Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.
 
  Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.
  
 
+
=== Known Issues ===
 
+
  - User with Domain Admins and Project Member
'''Known Issues'''
 
  - Mixing Domain Admin + Project Admin
 
 
  - Creating Members in the Default Admin domain
 
  - Creating Members in the Default Admin domain
 
  - Project Admin, hide Admin Dash on purpose
 
  - Project Admin, hide Admin Dash on purpose
 +
- Pure Domain Admin Create Project will not have a quotas tab. (will need Cloud Admin to adjust if not using default values)
  
'''Horizon Bugs'''
+
=== Horizon Bugs ===
- luigi (project member, invalid Catalog Service:compute)
 
- list_role_assignments (pure domain admin)
 
- Group manange members (pure domain admin)
 
 
  - Project details (pure project admin, member)
 
  - Project details (pure project admin, member)
 
  - checkboxes and actions when no actions available (member)
 
  - checkboxes and actions when no actions available (member)
  
'''Next Steps'''
+
=== Next Steps ===
 
  - DOA patch
 
  - DOA patch
 
  - Keystone patch
 
  - Keystone patch
 
  - Fix Horzon Bugs
 
  - Fix Horzon Bugs
- UX/UI - project picker, set domain context changes
 
 
  
'''Test Cases'''
+
=== Test Cases ===
  
  
'''Future'''
+
=== Future ===
 
  - angular goodness
 
  - angular goodness
 
  - persona driven workflows
 
  - persona driven workflows
 
  - keystone changes
 
  - keystone changes
 +
- quota management

Latest revision as of 00:06, 14 July 2015

(Work In Progress)

Use Cases

- LDAP, AD, MySQL support

Best Practices

Keystone v3 policy files

Horizon should use the same keystone v3 policy file as the keystone API

An new admin domain should be created

Cloud Admin should have an admin role in a domain specifically created for Identity management of the system.

Project Admin

Cloud Admin and Domain Admin are the preferred "admin" personas in the context of domains.
Project Admin is restricted to quota mgmt and listing roles, role_assignments by the current keystone v3 policy file.
Project Admin can not currently manage the members of it's project due to permissions for list_users.

Domain Admins and Project Admins should be mutually exclusive.

Domain Admin + Project Admin is not recommended

Only Cloud Admin(s) should have a role on an admin domain

Non-Cloud Admin users should not have a role on the default admin domain

Definitions

User Types / Personas

Cloud Admin
domain-scoped token, scoped to the ‘default’ domain. This is assuming that user have the ‘admin’ role assigned to him for the ‘default’ domain.
Domain Admin
domain-scoped token, scoped to the given domain. This is assuming that user have the ‘admin’ role assigned to him for the given domain. Cloud Admin is also the Domain Admin for the ‘default’ domain.
Project Admin
project-scoped token, scoped to the given project. This is assuming that user have the ‘admin’ role assigned to him for the given project.
Project User
project-scoped token, scoped to the given project. This is assuming that user have at least one role assigned to him for the given project. Project User is also Project Admin only if user also have the ‘admin’ role assigned to him for the given project.

Note:

Domain-scoped token should NOT have access to Nova. Only project-scoped token have access to the services. Cloud Admin and Domain Admin are Keystone-specific personas and therefore only have access to Keystone APIs.

Known Issues

- User with Domain Admins and Project Member
- Creating Members in the Default Admin domain
- Project Admin, hide Admin Dash on purpose
- Pure Domain Admin Create Project will not have a quotas tab. (will need Cloud Admin to adjust if not using default values)

Horizon Bugs

- Project details (pure project admin, member)
- checkboxes and actions when no actions available (member)

Next Steps

- DOA patch
- Keystone patch
- Fix Horzon Bugs

Test Cases

Future

- angular goodness
- persona driven workflows
- keystone changes
- quota management