This document discusses converting the authorization system in OpenStack's Keystone identity service from a single-tenant to a multi-tenant system. It proposes changing from a 3-tuple (subject, privilege, object) model to a 5-tuple (issuer, subject, privilege, interface, object) model incorporating roles and services. The implementation adds the service to credentials and rules dictionaries, represents roles as issuer-name tuples, and adds a check for service matching between credentials and rules to allow access. Directories and files used by Keystone are also outlined.

1. By-
Anush V
Meghana Prashanth
Pramod Ramesh
Ashwin Sethi

2. Introduction
 Openstack is an open source cloud service
implementation
 Keystone is the security module of Openstack
 Current authorization system implemented in
keystone is single-tenant
 Multi-tenancy support is defined as the capability
of a single software instance to provide its service
to several parties simultaneously
 Our objective is to convert this single tenant
system into a multi-tenant one

3.  Current implementations of authorization is based on a 3
tuple implementation namely (Subject, Privilege, Object)
 This needs to be changed to incorporate multi-tenancy
 The basic multi-tenant system would have a structure in the
form of a 5 tuple namely (Issuer, Subject, Privilege, Interface,
Object)
 This implementation though useful is not enough
 We try to use a RBAC incorporated implementation
 This new model which has RBAC changes the 5 tuple to
(Issuer, role(Issuer, RoleName), Privilege, Interface, Object)

4. (IssuerA, role(IssuerB, users), Read, ServiceA.1, root) is
interpreted as IssuerA grants anybody with role(IssuerB,
users) Read access to the root folder of the file system
provided by ServiceA.1.

5. Keystone Layout
 Keystone directories were found in the following
locations
 /opt/stack  This contained all the necessary
python modules to keep keystone running
including the policy engine
 /var/lib  This contained the keystone.db file
used to initialise the backend
 /usr/share  This contained shell files to
automatically crate new users in opentack
 /etc  This contained the keystone.conf file and
the default catalog templates file

6. Policy Trace
 Once an access is made to any protected resource the
authorization entry point is in rules.py
 enforce()  common.policy.enforce()  Brain.check()
 _check()  _check_rule() or _check_role() or
_check_service() or _check_generic() depending on the
match in the rules dictionary.
 These functions recursively call Brain.check() to help
matches nesting of rules appropriately.

7. Our Implementation
 To implement the 5 tuple we add the following to
the current implementation
 The Service as a part of both the cred_dict and
rules_dict
 The role is now a 2 tuple mapping between
issuer and name of the role, again this is added
to both cred_dict and rules_dict
 New function called _check_service is
implemented
 Access is allowed only if all the elements in the
match_list match that of the cred_dict

8. Thank You