3 Replies Latest reply on Jan 5, 2012 1:22 PM by Bill Robinson

    Using property dictionary to restrict access to servers



      I have a need to restrict server access by region, then country, then technology, then role.


      Currently this is nearly being managed by RBAC Roles and ACLs on Bladelogic and because we have 5 regions and each region has a few countries with the same or similar technologies (Lin, Win, Sol) and each technology needs to have a number of different roles assigned we have over 200 roles and an equal amount of Authorisations. Each role needs to have access only to the technology in the country of the region (eg, a developer role on windows for a Brazilian worker in the Americas region currently needs a role all to himself).


      I would rather if at all possible (also because of advise from BMC) start using the properties in server, user or any other class to restrict regional and if possible country and technology access thus reducing the amount of roles needed by a factor of 16.


      Any suggestions on how to manage/reduce the RBAC overload, would be greatfully appreciated

        • 1. Using property dictionary to restrict access to servers
          Bill Robinson

          if you need to grant access to a server, there needs to be a role object in existence.  so i'm not sure how much the property dictionary will help here. how exactly do you envision the property dictionary helping out here?


          you might be able to condense your authorization profiles used by the roles and acl templates and such.  but beyond that you can't really use properties to affect anything in rbac (other than user mappings)


          is there some commonality in your roles or authorizations between the roles? (eg, your brazil_win_admin and emea_win_admin roles could use the same authorization profile for example)

          • 2. Using property dictionary to restrict access to servers

            Hi Bill

            Thanks for the response.

            What is in place at present is a role is created as you suggested above, but as each role should only have access to servers in their region and there are currently five regions,  one role soon becomes five. Now they are looking to make that more granular as they want to create satellite roles which will prevent users at a local level accessing the main regional servers, but still give a level of access to the satellite servers which has the potential to increase the amount of roles exponentially.


            What I am trying to do is use the property dictionary in order to utilise smart groups more efficiently and then give roles access to the contents of these smart groups. So for instance, a server group called "ByRegion" will contain a sub group called "EMEA" which will contain smart groups for "Linux", "Windows" and "Solaris". The plan is to create a similar structure for "Countries", "Technology", "Availability" and "Status(dev,QA,Prod etc)". These smart groups will use classes in the Property dictionary which put the correct Region, Country and OS server into the smart groups. I am creating the same custom classes in the User class so can order users based on Region, Country, Technology and so on, but I am thinking I still need the same amount of roles in order to prevent cross region access.

            • 3. Using property dictionary to restrict access to servers
              Bill Robinson

              you can use properties to classify the servers and then use the smart groups to organize them - that's fine.


              you will need to have a role for every permission set that you want to create.  so if that's one role per region/os/status/tech/country that's what you will have.