Bug 1041920

Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/attribute-access-privilege-based-on-role.

Description:

The current implementation of Keystone supports RBAC on identity APIs; once the subject is authorized on a particular API (get/update) he/she is then able to access/modify all the attributes of the target (or object) which is being operated by the API. This approach is OK as long as the cloud provider does not want to enforce any restrictions on attribute(s) of the API's target -- but that is not the case with most of cloud providers.

Below are some of the example which need "Attribute Access Privilege Based on Role":

1. Cloud superadmin (most privileged identity role in a cloud system) should allowed to get/update all attributes from Domain/Project/User object but they should not be allowed modify the attributes which are system generated.

2. Domain admin (designated admin role for a domain) should only allowed to get/update certain attributes from Domain/Project/User object.

3. Domain user (without any privileged role) should only be allowed to get certain attributes from Domain/Project and should be allowed to update certain attributes (e.g. only the self service attributes) on his own User object.

For a more concrete example suppose there are following attributes of domain object:

    Name
    Status
    billing_credit_card
    system_generated_id

The cloud provider wants to impose following restrictions on attributes of domain object:

on identity:get_domain API

* "superadmin" should be allowed to get all attributes of domains.
* "domainadmin" should only be allowed to get Name, Status and billing_credit_card of their own domain.
* "domainuser" should only be allowed to get Name and Status of their own domain.

on identity:update_domain API

* "superadmin" should allowed to update all the attributes of domains except system_generated_id.
* "domainadmin" should only allowed to update Name and billing_credit_card of their own domain.

For user Self Service Example suppose there are following attributes of user object

    Name
    email_address
    password
    hmac_salt
    Status
    system_generated_id

The cloud provider wants to impose following restrictions on attributes of user object:

on identity:get_user API

* "superadmin" should allowed to get all the attributes of users except password and salt.
* "domainadmin" should only allowed to see Name, email_address and Status of users of their own domain.
* "domainuser" should only allowed to see Name, email_address of their own user object.

on identity:update_user API

* "superadmin" should allowed to update all the attributes of user except system_generated_id and hmac_salt.
* "domainadmin" should only allowed to update Name, email and status of user object.
* "domainuser" should allowed to update all attributes of his own object except hmac_salt, Status and system_generated_id.

As per the requirements outlined above, we need

- An ability to defined certain class of attributes for different objects.
- An ability to associate those attribute classes with roles.
- Enforce policy on certain API (mostly get and update) based on role Vs attribute class defined in #2.

Specification URL (additional information):

None