Bug 1041921

Summary: [RFE][keystone]: Attribute Based Access Control Model
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/keystone/+spec/attribute-based-access-control
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:12:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 20:05:18 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/attribute-based-access-control.

Description:

Our motivation is based on discussion of Attribute Based Access Control (ABAC) VS. Role Based Access Cotrol (RBAC) in the mailing list: http://lists.openstack.org/pipermail/openstack-dev/2012-November/003265.html.

In large organization, there are great needs of fine-grained access control over the resources. The current authorization process makes use of only one user attribute namely role. RBAC is not designed to express flexible and dynamic access control. RBAC shows its advantages in administration because of the assumption that role-permission assignment is static.
Attribute based access control (ABAC) is regarded as the candidate to achieve flexible and dynamic access control. Attributes are associated with users (e.g., organization, department, role), objects (i.e., resources)  (e.g. owner, size) and environment (e.g. time, location). Access requests are evaluated based on the attributes of involved entities. For instance, for training purpose, a university temporarily allows all full time student users who are currently registered in course CS3423 to login the university cloud (with their school id which has been stored in the cloud) to create virtual machines with only ubuntu images. With ABAC, the IT administrator only needs to insert one policy, compared with the work of creating role, assigning permissions to role, and assigning users to roles explicitly in RBAC model.

This blueprint proposes to implement Attribute based access control (ABAC). The basic scope is to provide mechanisms to configure and enforce ABAC policies. Security architect manages attributes, write and enforce authorization policies on specific scope (e.g., project). Administrators of the cloud manages (admin or delegate) users and their attributes.
Our ultimate goals are: provide the mechanism to configure attribute based access control.
Initial keystone client side command and server APIs have been implemented. Example keystone client commands keystone attribute-create which creates a new attribute, keystone attribute-value-create which defines new allowable for an attribute.

More information is on project page: http://my.cs.utsa.edu/~xjin/abac.htm

Specification URL (additional information):

None