Using CA AppLogic® › Grid Administration Guide › Role-Based Access Control › Example Security Scheme with RBAC

Example Security Scheme with RBAC

CA AppLogic® does not provide an extensive scheme of pre-defined groups and users. This allows grid administrators to set up users, groups and object access to suit each particular situation. In general, grid administrators follow these steps:

• Create local users.
• Create a set of local groups. These group may be used to segregate users by type of work (for example, grid administration, application development, QA, etc.), business structures (for example, by department or business unit so that different groups of users may share a grid for their development work) or other practical divisions. The same effect can be achieved also with global groups, which is especially useful when the same setup is used for two or more grids.
• Add users to groups, or groups to groups, as appropriate.
• Modify object ACLs to assign groups specific access level rights.

The following scenario provides a practical example of how this process can work to effectively control user access.

Ace Starships Incorporated (ASI) builds space craft. Each space craft includes software systems for life support and propulsion among many others. These two software systems are developed on a large shared CA AppLogic® grid before being deployed to production grids on actual space craft. The development process on this grid includes the following parties:

• Life Support development team
• Propulsion development team
• Outsiders – specialists in middleware appliance development (common appliances)
• Auditors – ASI personnel who require non-destructive access to development
• QA – quality assurance personnel who test the products of both development teams and the Outsiders

In addition we also have:

• A global user john_adams who is a grid administrator – the person responsible for grid administration
• A global user jane_osprey who is a grid operator – the person responsible for the grid when the grid administrator is sleeping

Furthermore:

• ASI uses a company-wide LDAP based directory service for centralized user and group management. Everyone but the Outsiders has an account on this system.
• The propulsion team uses several applications created by the life support team, but does not modify the architecture of these applications.
• Both teams use appliances developed by the Outsiders, but do not modify these appliances.
• There are global catalogs which contain appliances specific to the different development efforts: life_support, propulsion and outsiders.

One of the first decisions to make in this scenario is whether to manage group membership using the company-wide directory, or whether to manage this membership using local groups. In this example we take the first approach:

• Using the ASI company-wide directory, create groups life_support, propulsion, QA and auditors and include in these groups the corresponding global users. This operation is performed outside of CA AppLogic®.

Going forward with our example, the initial CA AppLogic® user, who is a member of the local group admin, performs the following user and group set up:

• Create a local user account for each of the Outsiders.
• Create the following local groups:
  • outsiders
  • grid_operators
  • app_developers
• Set up group membership:
  • Add the created local users to the local group outsiders.
  • Add the global groups life_support, propulsion and QA to the app_developers group.
  • Add the local group outsiders to the app_developers group.
  • Add the global user john_adams to the admin group
  • Add the global user jane_osprey to the grid_operators group
• Modify object ACLs to set up object access:
  • Modify the grid ACL to:
    • Provide grid_operator access level rights to the local group grid_operators.
    • Provide app_developer access level rights to the local group app_developers.
    • Provide monitor access level rights to the global group auditors.
  • Modify global catalog ACLs to:
    • Provide full access level rights on the life_support catalog to the global group life_support, on the propulsion catalog to the global group propulsion, and on the outsiders catalog to the local group outsiders.
    • Provide configure access level rights on the outsiders catalog to the local group app_developers, and on the life_support catalog to the global group propulsion.

The following tables show group membership in our scenario:

The following table shows access level rights granted to principals for pertinent objects in our scenario:

The initial set up of users and groups is now complete. At this point global users belonging to the global groups life_support, propulsion, QA and auditors can all log in to the grid, and each user is automatically provided the necessary access level rights to perform their work.

Access to the global catalogs has also been set up so that appliances are accessible as required, but only members of the group which has full access level rights on a catalog can perform destructive operations on that catalog.

When a user creates a new application, that user becomes the application owner and is granted full access level rights on that application. At some point, the user may want to modify the application ACL to give other members of his development team, or of another team, access to the application. For example:

• A member of the life support team can grant the local group life_support full access level rights on the application so that other team members can modify it at will.
• A member of the life support team can grant the local group propulsion configure access level rights to the application so that members of this group can configure or use the application but cannot modify its architecture.
• A member of the life support team can grant the global group QA whatever access level rights are necessary for testing the application (for example, read access to make a copy of the application for separate testing, configure access to configure or use the application without modifying its architecture, etc.).