7.8. Role Based Authentication

Assigning a role to a user enables controlling access to Satellite components based on a set of permissions. You can think of role based authentication as a way of hiding unnecessary objects from users who are not supposed to interact with them.

There are various criteria for distinguishing among different roles within an organization. Apart from the administrator role, the following types are common:

  • Roles related to applications or parts of infrastructure – for example, roles for owners of Red Hat Enterprise Linux as the operating system versus owners of application servers and database servers.
  • Roles related to a particular stage of the software life cycle – for example, roles divided among the development, testing, and production phases, where each phase has one or more owners.
  • Roles related to specific tasks – such as security manager or license manager.

When defining a custom role, consider the following recommendations:

  • Define the expected tasks and responsibilities – define the subset of the Satellite infrastructure that will be accessible to the role as well as actions permitted on this subset. Think of the responsibilities of the role and how it would differ from other roles.
  • Use predefined roles whenever possible – Satellite provides a number of sample roles that can be used alone or as part of a role combination. Copying and editing an existing role can be a good start for creating a custom role.
  • Consider all affected entities – for example, a content view promotion automatically creates new Puppet Environments for the particular life cycle environment and content view combination. Therefore, if a role is expected to promote content views, it also needs permissions to create and edit Puppet Environments.
  • Consider areas of interest – even though a role has a limited area of responsibility, there might be a wider area of interest. Therefore, you can grant the role a read only access to parts of Satellite infrastructure that influence its area of responsibility. This allows users to get earlier access to information about potential upcoming changes.
  • Add permissions step by step – test your custom role to make sure it works as intended. A good approach in case of problems is to start with a limited set of permissions, add permissions step by step, and test continuously.

For instructions on defining roles and assigning them to users, see Managing Users and Roles in the Administering Red Hat Satellite guide. The same guide contains information on configuring external authentication sources.