2.2    Privilege Validation and Assignment

Now that we’ve discussed the five different types of privileges available, let’s take a moment to show you how they’re assigned to user accounts and how the system validates these privileges.

2.2.1    Assigning Privileges

Figure 2.1 shows how privileges should be assigned, with the user account (to which multiple roles can be assigned) at the top, roles in the middle, and the assignment of the different types of privileges at the bottom. When a user interacts with SAP HANA, the system validates the user’s privileges by checking those assigned directly to that user or those inherited from an assigned role. Privileges can be assigned directly to a user account, but we recommend that user accounts be assigned one or more roles, and roles are then assigned one or more privileges. We highly recommend that you adhere to this methodology when designing a security model.

SAP HANA Privilege Assignment Hierarchy

Figure 2.1    SAP HANA Privilege Assignment Hierarchy

Roles are database objects used to organize and assign privileges to one or more users. Managing privileges for each individual user account is not scalable in most large environments. Administrators prefer using roles because typically you’ll need only a few roles to manage. Roles help promote a consistent application of privileges and can be shared by multiple user accounts. A variety of roles can be created, and each role can contain a variety of different privileges.

In subsequent chapters, we’ll discuss the processes for creating users, creating roles, and assigning privileges in detail. For now, we just want to highlight the basic process used to grant or assign privileges to users.

2.2.2    Validating Privileges

Now that you have a basic understanding of how privileges are assigned to users, let’s take a moment to discuss how these privileges are validated when a user attempts to perform an action in the system. In this section, we’ll discuss two broad categories of validation that we’ll discuss: First is basic validation. This type of validation comes into play when a user attempts to access an object or perform an action directly. Second, we’ll discuss how the system validates privileges when an object references other objects. For example, how does the system fully validate a stored procedure that references other catalog objects in the system?

Basic Validation

When validating privileges, the system checks for privileges assigned directly to the user and privileges assigned to roles that are also assigned to the user. This process is basic authorization validation. SAP HANA currently only supports granting privileges, not denying them. SAP HANA simply looks at the user’s privileges and the privileges assigned to its roles. If SAP HANA finds a privilege granted, it stops the validation process and assumes that the user is allowed and authorization granted. Because SAP HANA does not support denied privileges, the system does not need to check all assigned privileges.

Validation for Catalog Objects Referencing Other Objects

Some catalog objects can be developed referencing other catalog objects, and both catalog views and catalog-stored procedures represent objects that facilitate this scenario. Let’s start by defining two classes of objects: First, the parent object contains one or more referenced objects. Parent objects are also sometimes objects with dependencies. For example, if a catalog view references three catalog tables, the view is the parent object referencing the catalog tables. Second, referenced child objects are the objects contained within the definition of the parent object. The parent object references these objects or is dependent on them.

The system validates privileges for parent catalog objects with dependencies using the following rules:

  1. The user account accessing the parent object must have explicit object privileges to access it. For example, if you create a catalog view that references tables in three schemas, the user account must have SELECT access to the catalog view regardless of the privileges specified on the referenced table objects.

  2. The developer that creates the parent object must have the required privileges for the child object and must have the ability to grant those privileges to other users. For example, if you create a catalog view that references tables in three schemas, the developer must have SELECT access to the objects in those schemas. He must also have the WITH GRANT OPTION/Grantable to Others right to delegate those privileges to other users.

  3. Stored procedures created using the definer mode are validated using rules 1 and 2. The end user only needs privileges to access the stored procedure. The objects that the stored procedure references are validated against the developer’s privileges during activation. Effectively, the developer is indirectly granting user access to the child referenced objects.

  4. Stored procedures created using the invoker mode are validated differently. The end user accessing the stored procedure must have explicit catalog object privileges for both the parent object and the referenced child objects. This option changes the default behavior of dependent objects and is used when the procedure is attempting to manipulate objects that should be validated against the executing user’s privileges rather than the designer’s privileges.

Note that catalog stored procedures have unique options to change the default validation behavior.

Validation for Packages and Development Artifacts

As discussed earlier, packages are nodes organized in a parent-child relationship. Together, packages make up the SAP HANA repository. Each package contains a subpackage or one or more development artifacts. Package privileges are assigned at the package node. Development artifacts cannot individually or explicitly be granted privileges. However, development artifacts do inherit the privileges assigned to their parent and grandparent package nodes. When the validating access to a development artifact, the system first checks the privileges assigned to the direct parent package. If no privileges have been assigned to the direct parent, the system will continue to traverse up the hierarchy, checking each grandparent node until it can validate the requested action. If no parent or grandparent node has assigned privileges for that user, the user fails the authorization and is not authorized to perform the requested action. This process is known as the bottom-up approach to authorization validation.

Because SAP HANA uses a bottom-up approach, you only need to grant the user privileges on its closest desired parent or grandparent package. In other words, you don’t need to establish privileges for a given user at each level of a package hierarchy. Understanding this distinction will help you avoid overengineering your security model.

Note that developers will likely need a combination of package, system, and object privileges to fully manage content in the package repository. For example, the REPO.MODIFY_CHANGE system privilege might be required to allow the user the ability to activate content when change management is required. The user might also need the REPO.IMPORT and REPO.EXPORT system privileges to import and export repository delivery units. To access the package repository, a developer will need the EXECUTE object privilege for the SYS.REPOSITORY_REST stored procedure. Thus, package privileges alone do not always provide the required access to the system. Throughout this book, we’ll explore various privileges and how they’re layered together in roles. For now, we just want to highlight that privileges are often layered to grant complete access to some areas within SAP HANA.