|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| − | __NOTOC__
| |
| − | A Role Mapping Service for the Keystone Identity Server
| |
| | | | |
| − | Version Date Author(s) Comments
| + | Describe keystone/RoleMappingService here. |
| − | 0.1 20 November 2012 Kristy Initial Document Creation
| |
| − | 0.2 21 November 2012 David Significant mods
| |
| − | 0.3 21 November 2012 Kristy Added diagram and use case
| |
| − | | |
| − | Introduction
| |
| − | | |
| − | In order to fully realize both federated identity management in Keystone and several use cases of a centralised Keystone, a service must be introduced to allow administrators of organisations to translate a large and varying set of their organisational attributes (or roles) issued by themselves or any Identity Provider in the supported federation(s), into the service roles assigned by the Openstack administrator to determine the usage permissions for the cloud services that are available. We propose that this “Role Mapping” service be implemented as part of Keystone and this document describes the requirements of this service as well as a look at some possible implementation details with regard to the existing Keystone service.
| |
| − | Terminology. We will use the term “organisational attribute” to refer to the original attribute or role that a user possesses by virtue of his role in an organisation, or account with an Identity Provider. We will use the term “role” to refer to the roles used by [[OpenStack]] services to authorise users to access cloud resources. The role mapping service will map from organisational attributes to roles.
| |
| − | Current Role Assignment in Openstack
| |
| − | | |
| − | Roles in Openstack services are used to determine access rights in the various Openstack services. Each service has its own policy.json file, which describes the access each role permits. Roles are then created and assigned in Keystone.
| |
| − | Proposed Changes
| |
| − | | |
| − | The following objectives should be met by a role mapping service:
| |
| − | 1. The organizational administrator should be able to add any organisational attributes to a set and then map this set to one or more [[OpenStack]] roles.
| |
| − | 2. The organizational administrator should be able to remove set associations, attribute sets and mappings. The organisational administrator should NOT be able to remove or add roles to [[OpenStack]].
| |
| − | 3. The Keystone administrator should be able to grant permission to users with admin roles to control the mapping of a set of Openstack roles on a user-by-user or administrative role basis.
| |
| − | 4. The Keystone administrator should be able to revoke the permissions of users with admin roles to control the mapping of [[OpenStack]] roles.
| |
| − | 5. Given a set of organizational attributes, keystone should return the set of Openstack roles which they have been mapped into.
| |
| − | 6. All new entities should be have listing utilities e.g. role-set-list
| |
| − | | |
| − | We propose adding a number of entities to WHAT? to represent each part of a role mapping:
| |
| − | | |
| − | i) Attribute set represent a set of organizational attributes, which can be mapped to a set of Openstack roles.
| |
| − | | |
| − | Additional required attributes:
| |
| − | · name (string)
| |
| − | o Unique user friendly attribute set name
| |
| − | Optional Attributes:
| |
| − | · description(string)
| |
| − | o Description of the attribute set
| |
| − | Entity example:
| |
| − | {
| |
| − | “attribute-set”: {
| |
| − | “id”:”123456”,
| |
| − | “name”:”[[KentStaff]]”,
| |
| − | “description”:”Staff at Kent”
| |
| − | }
| |
| − | }
| |
| − | | |
| − | ii) Organisational attribute represent an attribute or role that can be assigned by an Identity Provider or organisation to a person (or cloud user).
| |
| − | | |
| − | Additional required attributes:
| |
| − | · name (string)
| |
| − | o Unique user friendly attribute name
| |
| − | · type(string)
| |
| − | o Type of attribute as identified by IdP or organisation
| |
| − | | |
| − | Optional Attributes:
| |
| − | · description(string)
| |
| − | o Description of the attribute
| |
| − | · value(string)
| |
| − | o The value of the attribute defined
| |
| − | Entity example:
| |
| − | {
| |
| − | “org-attribute”: {
| |
| − | “id”:”789012”,
| |
| − | “name”:”[[StaffRoleKent]]”,
| |
| − | “type”:” unikentaccountType”,
| |
| − | “value”:”staff”,
| |
| − | “description”:”Staff account type at Kent Uni”
| |
| − | }
| |
| − | }
| |
| − | | |
| − | iii) An Attribute set association represents an association between an attribute set entity and an organisational attribute.
| |
| − | | |
| − | Additional required attributes:
| |
| − | · attribute-set-id(string)
| |
| − | o ID of the role set to associate
| |
| − | · org-attribute-id(string)
| |
| − | o ID of the organizational role to associate
| |
| − | | |
| − | Entity example:
| |
| − | {
| |
| − | “attribute-set-association”: {
| |
| − | “id”:345678,
| |
| − | “attribute-set-id”:”123456”,
| |
| − | “org-attribute-id”:”789012”
| |
| − | }
| |
| − | }
| |
| − | iv) A Role set represents a set of Openstack roles, which can be mapped to a set of organisational attributes.
| |
| − | | |
| − | Additional required attributes:
| |
| − | · name (string)
| |
| − | o Unique user friendly role set name
| |
| − | Optional Attributes:
| |
| − | · description(string)
| |
| − | o Description of the role set
| |
| − | Entity example:
| |
| − | {
| |
| − | “role-set”: {
| |
| − | “id”:”123456”,
| |
| − | “name”:”admin-roles”,
| |
| − | “description”:”Roles for administration of the service”
| |
| − | }
| |
| − | }
| |
| − | | |
| − | v) A Role set association represents an association between a role set entity and a role.
| |
| − | | |
| − | Additional required attributes:
| |
| − | · role-set-id(string)
| |
| − | o ID of the role set to associate
| |
| − | · role-id(string)
| |
| − | o ID of the organizational role to associate
| |
| − | | |
| − | Entity example:
| |
| − | {
| |
| − | “role-set-association”: {
| |
| − | “id”:345678,
| |
| − | “role-set-id”:”123456”,
| |
| − | “role-id”:”789012”
| |
| − | }
| |
| − | }
| |
| − | | |
| − | vi) A role mapping entity maps a role set entity to an attribute set entity
| |
| − | | |
| − | Required attributes:
| |
| − | · attribute-set-id(string)
| |
| − | o ID of the role set to associate
| |
| − | · role-set-id(string)
| |
| − | o ID of the role to map
| |
| − | | |
| − | Entity example:
| |
| − | {
| |
| − | “role-mapping”: {
| |
| − | “id”:901234,
| |
| − | “attribute-set-id”:”123456”,
| |
| − | “role-set-id”:”567890”
| |
| − | }
| |
| − | }
| |
| − | | |
| − | vii) A role assignment permission represent a permission granted to an administrative role, to map a (normal) role to a role set (and hence to organisational attributes). For example, the Keystone administrator may define the following roles: admin, member and mapper. The first two are (normal) roles which are given to users to authorise them to access [[OpenStack]] services. The last role is an admin role which will be given to (administrative) users to authorise them to perform role mapping on normal roles. So the mapper role may be given permission to map the admin and member roles. Existing procedures are used to assign the mapper role to (administrative) users.
| |
| − | | |
| − | Required attributes:
| |
| − | · adminRole-id(string)
| |
| − | o ID of the admin role being granted permission to manage the normal role
| |
| − | · role-id(string)
| |
| − | o ID of the normal role that can be mapped
| |
| − | | |
| − | Entity example:
| |
| − | {
| |
| − | “role-assignment-permission”: {
| |
| − | “id”:”654321”,
| |
| − | “adminRole-id”:”098765”,
| |
| − | “role-id”:”567890”
| |
| − | }
| |
| − | }
| |
| − | Example Entity Diagram
| |
| − | | |
| − | Figure 1 shows some example mappings. This represents two role mappings:
| |
| − | | |
| − | The Openstack “admin” role is mapped to an attribute set with two associated attributes
| |
| − | organisation: kent
| |
| − | accountType: staff
| |
| − | The Openstack “member” role is mapped to two attribute sets, each with two associated attributes
| |
| − | organisation: kent
| |
| − | accountType: student
| |
| − | and
| |
| − | * '''a)''' organisation: kent
| |
| − | b. accountType: staff
| |
| − | | |
| − | Example use cases:
| |
| − | | |
| − | Case 1:
| |
| − | | |
| − | User Fred is a lecturer at the University of Kent, among his attributes are the organisation=kent attribute and the accountType=staff attribute, he logs into Keystone and is granted the “admin” role AND the “member” role.
| |
| − | | |
| − | Case 2:
| |
| − | | |
| − | User Betty is an undergraduate student at the University of Kent, among her attributes are the organisation=kent attribute and the accountType=student attribute, she logs into Keystone and is granted the “member” role
| |
| − | | |
| − | Case 3:
| |
| − | | |
| − | User Wendy is an undergraduate student at the University of Bristol among her attributes are the organisation=bristol attribute and the accountType=student attribute, she logs into Keystone and is not granted either role.
| |
| − | | |
| − | Figure 1
| |
| − | | |
| − | Role Mapping in a Non-Federated Environment
| |
| − | | |
| − | In a non-federated (centralised) installation, authenticated users, whilst they have organisational attributes, these are currently not given to or retrieved by Keystone. There are a number of possible solutions to this:
| |
| − | 1. When the user authenticates, he provides his username, password and organisational roles to Keystone.
| |
| − | 2. After the user authenticates, Keystone retrieves the user’s organisational roles from the user’s entry in the Keystone database (LDAP or other).
| |
| − | 3. After the user authenticates, the client retrieves the user’s organisational roles from the organisation’s LDAP or similar directory service and passes them to Keystone.
| |
| − | | |
| − | Case 1 is insecure and can only be used with trusted users.
| |
| − | Case 2 will require changes to the Keystone backend authentication service but not to the front end API
| |
| − | Cases 1 and 3 will require changes to the Keystone API to pass the organisational roles to Keystone
| |
