The RBAC Hat Trick: Users, Groups and Roles in BMC Database Automation

I’ve been a hockey fan as long as I can remember. Growing up on the frozen shores of Lake Ontario, nearly every kid laced up the skates and hit the ice at an early age. In my hometown we even had a pretty good minor league team to cheer on.


avery.jpgContrary to popular belief, there’s a lot more to the game than guys chasing a rubber disk and taking the occasional whack at it (and each other) with a stick. There are all kinds of strategies employed by teams to create a competitive advantage. One of these strategies is the use of Role Players. There are lots of roles that players take on based on their particular skills and the needs of the team. These include Scorers, Checkers, Penalty Killers, and the ever-popular Enforcers (shown at left).


Roles are equally important in Service Automation. By understanding the specific needs of users in the different organizations and functions in your business, you can setup your Service Automation tools to accommodate business needs without creating excessive risk and bringing on undue scrutiny from the security team.


In BMC Database Automation, Role-Based Access Control (RBAC) provides a lot of flexibility when setting up the security model for your users. Let’s look at a few basics.


In BDA, you create a User for each individual that will be logging into the system. It goes without saying that each person should be given their own user account – sharing should be highly discouraged.


Users are organized into Groups; each group is granted a Role on one or more domains. Roles are simply sets of BDA capabilities. There are many different capabilities in BDA, including things like “Apply an Oracle Patch”, “Provision a SQL Server Instance”, “Create a Template” and so on. In all, there are more than seventy individual capabilities in BDA. Some of the possible relationships in the RBAC model are illustrated below.


RBAC Picture.jpg


For example, you could create a role called Operations and define it with the capabilities “Oracle Provisioning”, “Oracle Patch Apply”, and “Oracle Patch Rollback”. You then create user wgretzky, assign him to group OraDBAs, and grant OraDBAs the Operations role on domain “/Production”. Our friend Mr. Gretzky (holder of 61 NHL records, by the way) can then perform his provisioning and patching tasks on Oracle databases in the /Production domain without the ability to change (or even see) databases in other domains.

There are a few interesting things to note in this model:

  • Users can be members of more than one group
  • A group can be granted different roles on different domains
  • A group can be granted the same role on different domains
  • A group can be granted multiple roles on one domain. When this happens, the group’s capabilities for that domain are simply the union of the capabilities in each role
  • Granting a role on a parent domain will grant access to all of the parent’s subdomains, both current and future.


For hockey fans and non-fans alike, the BDA RBAC model affords tremendous flexibility in setting up security for your users. With careful planning, you can leverage this flexibility to organize your user community in a way that meets your organizations’ security requirements.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post