Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  1. 1. By- Anush VMeghana Prashanth Pramod Ramesh Ashwin Sethi
  2. 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. 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. 4. (IssuerA, role(IssuerB, users), Read, ServiceA.1, root) isinterpreted as IssuerA grants anybody with role(IssuerB,users) Read access to the root folder of the file systemprovided by ServiceA.1.
  5. 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. 6. Policy Trace Once an access is made to any protected resource the authorization entry point is in 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. 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. 8. Thank You