HA940 EN Col17

HA940
SAP HANA 2.0 SPS05 -

Authorizations, Scenarios &
Security Requirements
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 17
Course Duration: 2 Day(s)
Material Number: 50157407
SAP Copyrights, Trademarks and
Disclaimers
© 2022 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see https://www.sap.com/corporate/en/legal/copyright.html for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials may have been machine translated and may contain grammatical errors or
inaccuracies.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.
© Copyright. All rights reserved. iii

Typographic Conventions
American English is the standard used in this handbook.

The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Demonstration
Procedure
Warning or Caution
Hint
Related or Additional Information
Facilitated Discussion
User interface control Example text
Window title Example text
iv © Copyright. All rights reserved.

Contents
vii Course Overview
1 Unit 1: Introducing SAP HANA Security
3 Lesson: Introducing SAP HANA

9 Lesson: Outlining security functions
19 Lesson: Describing SAP HANA implementation scenarios
29 Unit 2: Using SAP HANA administration tools
31 Lesson: Using security administration tools
39 Unit 3: Managing users
41 Lesson: Comparing User Types

47 Lesson: Managing User Groups
53 Lesson: Describing User Administration Tools
71 Unit 4: Implementing authorizations in the SAP HANA Database
73 Lesson: Describing object ownership rules

79 Lesson: Introducing Authorizations in the SAP HANA Database
89 Lesson: Introducing database roles management
93 Lesson: Creating Catalog Roles
99 Lesson: Creating HDI roles
109 Lesson: Comparing Role Types
115 Unit 5: Setting up personal database user accounts
117 Lesson: Set up personalized database administrator users
125 Unit 6: Managing authentication
127 Lesson: Managing Authentication
149 Unit 7: Enabling cross-database authorization in tenant databases
151 Lesson: Describing Cross-Database Authorizations in Tenant

Databases
159 Unit 8: Analyzing users and authorizations
161 Lesson: Tracing authorization errors

167 Lesson: Viewing Information about Users and Authorizations
173 Unit 9: Using Audit Logging
175 Lesson: Using Audit Logging

185 Lesson: Managing Audit Logging
© Copyright. All rights reserved. v

vi © Copyright. All rights reserved.
Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
● Database Administrator
● System Administrator
© Copyright. All rights reserved. vii

viii © Copyright. All rights reserved.
UNIT 1 Introducing SAP HANA Security
Lesson 1
Introducing SAP HANA 3
Lesson 2
Outlining security functions 9
Lesson 3
Describing SAP HANA implementation scenarios 19
UNIT OBJECTIVES
● Describe basic features of SAP HANA

● Outline the security functions in SAP HANA
● Describe SAP HANA implementation scenarios
© Copyright. All rights reserved. 1

Unit 1: Introducing SAP HANA Security
2 © Copyright. All rights reserved.

Unit 1
Lesson 1
Introducing SAP HANA
LESSON OBJECTIVES
After completing this lesson, you will be able to:
SAP HANA Overview

SAP HANA is an in-memory platform for performing real-time analytics and for developing
and deploying real-time applications. For on-premise deployment, SAP HANA comes either
pre-installed on certified hardware provided by an SAP hardware partner (appliance delivery
model) or must be installed on certified hardware by a certified administrator (tailored data
center integration model).
However, SAP HANA is more than a database management system. It is also a
comprehensive platform for the development and execution of native data-intensive
applications that run efficiently in SAP HANA, taking advantage of its in-memory architecture
and parallel execution capabilities.
The SAP HANA Database

At the core of SAP HANA is the high-performance, in-memory SAP HANA database.
SAP HANA XS and Development Infrastructure
SAP HANA includes the SAP HANA extended application services (SAP HANA XS), a
layer on top of SAP HANA that provides the platform for running SAP HANA-based Web
applications.
Figure 1: SAP HANA: The Platform for All Applications

Introducing the SAP HANA Database

The SAP HANA Database
At the core of SAP HANA is the high-performance, in-memory SAP HANA database.
SAP HANA is an in-memory platform that combines an ACID-compliant database with
advanced data processing, application services, and flexible data integration services. The
SAP HANA database can act as a standard SQL-based relational database. In this role, it can
serve as either the data provider for classical transactional applications (OLTP) or as the data
source for analytical requests (OLAP). Database functionality is accessed through an SQL
interface.
Standard Database Interfaces

SAP HANA provides standard database interfaces, such as, JDBC and ODBC and
supports standard SQL with SAP HANA-specific extensions.
Data Provisioning
Several data provisioning mechanisms are available for obtaining data from different
sources and accessing it in SAP HANA. For example, in a data mart or analytics scenario,
data is replicated into SAP HANA from source systems using one of the supported
replication technologies. For applications that use SAP HANA as their primary database
(such as, SAP S/4HANA), data is created directly in SAP HANA.
Data Recovery
Although the SAP HANA database holds the bulk of its data in memory for maximum
performance, it still uses persistent storage to support system restart and recovery.
There is minimal delay and no loss of data in the event of failure. For example, after a
power failure, the database can be restarted like any disk-based database and returned
to its most recent consistent state. In addition, SAP HANA provides functions for backup
and recovery, as well as high availability (disaster recovery and fault recovery).
Introducing SAP HANA XS and Development Infrastructure

SAP HANA includes the SAP HANA XS, a layer on top of SAP HANA that provides the platform
for running SAP HANA-based Web applications.
SAP HANA XS, Advanced Model

Available since SAP HANA 1.0 SPS 11, the SAP HANA XS advanced model represents an
evolution of the application server architecture within SAP HANA by building upon the
strengths (and expanding the scope) of SAP HANA extended application services, classic
(XSC) model.
The SAP HANA XS advanced platform supports several programming languages and
execution environments, such as, Java, and Node.js. The SAP HANA XS advanced application
run-times are invoked over HTTP and communicate with the SAP HANA database via SQL.
The database part of an SAP HANA XS advanced application (for example, the definitions of
tables, views, and procedures) is deployed using the SAP HANA deployment infrastructure
(SAP HANA DI, or HDI). HDI is a service layer of the SAP HANA database that simplifies the
consistent deployment of SAP HANA database objects. It supports isolated deployment
containers, which can be used, for example, to deploy several instances of the same
application on the same SAP HANA database.
SAP Web IDE for SAP HANA is the browser-based development environment for SAP HANA-
based applications. It can be used to develop all layers of an application, including UI, XS

Lesson: Introducing SAP HANA
advanced server applications, and SAP HANA database content. It is based on SAP HANA XS
advanced and HDI, and uses Git for source code management.
Note:
SAP recommends that customers and partners who want to develop new
applications use SAP HANA XS advanced model. If you want to migrate existing
XSC applications to run in the new XS advanced run-time environment, we
recommend that you first check the features available with the installed version of
XS advanced; if the XS advanced features match the requirements of the XS
classic application you want to migrate, then you can start the migration process.
For more information, see the SAP HANA XS Advanced Migration Guide.
Hint:
SAP HANA Extended Application Services, advanced model, is backwards
compatible; you can provide access to new features by installing the latest
version of the XS advanced component even on older versions of SAP HANA.
SAP HANA XSC Model

SAP HANA XSC is the original implementation of SAP HANA XS. The classic XS server is fully
integrated into the SAP HANA database and provides application server functions. Accessible
through HTTP, the XS server can deliver data through Open Data Protocol (OData) calls and
HTML UIs. For creating new structures and programs, for example, modeling database
structures, analytical queries, reports and procedures, as well as developing applications,
SAP HANA provides a development environment. This development environment is
integrated into the SAP HANA studio and the SAP HANA Web-based Development
Workbench. Design-time artifacts, such as, custom applications, roles, and application
content, are managed in SAP HANA's built-in repository. Design-time objects can be
transported from development systems to test and production systems.
Note:
SAP HANA XSC and the SAP HANA repository are deprecated as of SAP HANA
2.0 SPS 02. For more information, see SAP Note 2465027.
Describing Isolation of Database Tenants

An SAP HANA system comprises multiple isolated databases and may consist of one host or
a cluster of several hosts (scale-out system).
An SAP HANA system, identified by a single system ID (SID), contains one or more tenant
databases and one system database. Databases are identified by a SID and a database name.
From the administration perspective, there is a distinction between tasks performed at
system level and those performed at database level. Database clients, such as, the SAP HANA
cockpit, connect to specific databases.
All the databases in a system share the same installation of database system software, the
same computing resources, and the same system administration. However, each database is
self-contained and fully isolated with its own set of database users, database catalog,
persistence, and so on.

Figure 2: Multiple-Container System
Database Isolation
System Database
The system database, which is created during installation, is used for central system
administration, for example, the creation of tenant databases and global system
configuration. The system database stores overall system landscape information, including
knowledge of the tenant databases that exist in the system. However, it doesn't own
database-related topology information, that is, information about the location of tables and
table partitions in databases. Database-related topology information is stored in the relevant
tenant database catalog.
Tenant Database
Every tenant database is self-contained and isolated in terms of users, database catalog,
repository, logs, and so on. However, to protect against unauthorized access at the operating
system (OS) level, it's possible to increase isolation further through OS user separation and
authenticated communication within databases.

Lesson: Introducing SAP HANA
Figure 3: Database Isolation
Authenticated Communication
In addition, once high isolation has been configured, internal database communication is
secured using the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protocol.
Certificate-based authentication is used to ensure that only the processes belonging to the
same database can communicate with each other. It is also possible to configure internal
communication so that all data communication within the databases is encrypted.
Note:
If cross-database access is enabled, communication between configured tenant
databases is allowed.
Internal database communication is secured with the same mechanism used for securing
other internal SAP HANA communication channels. Once high isolation has been configured,
authenticated communication within databases is enabled without any change required to the
default TLS/SSL configuration for internal communication. However, encryption of data
communication may need to be configured explicitly.
OS User Separation
By default, all database processes run under the default OS user <sid>adm. If it's important
to mitigate against cross-database attacks through OS mechanisms, you can configure the
system for high isolation. In this way, the processes of individual tenant databases must run
under dedicated OS users belonging to dedicated OS groups, instead of all database
processes running under <sid>adm. Database-specific data on the file system is then
protected using standard OS file and directory permissions.
You can specify the isolation level of the system during installation. The default isolation level
is low. It’s also possible to change the isolation level of an existing system (from low to high or
from high to low) at any time. For more information, see Increase the System Isolation Level
in the SAP HANA Administration Guide. Once high isolation has been configured, a dedicated
OS user and group must exist for every tenant database. Otherwise, it is not possible to
create or start a tenant database.

LESSON SUMMARY
You should now be able to:

Unit 1
Lesson 2
Outlining security functions
LESSON OBJECTIVES
Outlining Security Functions

The goal of SAP HANA security is to protect data from unauthorized access.
Protecting Data from Unauthorized Access

The key aspects of data protection are as follows:
● User and role management

Every tenant database has its own database users and roles, including a tenant database-
specific superuser SYSTEM.
● Authentication
Only people who need to carry out tasks should be able to log on to the system.
● Authorization
Users in the system should only be able to see and do what they need to fulfill their tasks.
● Encryption
Protect data saved to disk from unauthorized access at operating system level.
● Auditing
There should be a record of critical user actions in the system.
● Masking and anonymization
Data masking is an additional layer of access control that can be applied to tables and
views. Anonymization allows you to gain statistically valid insights from your data while
protecting the privacy of individuals.
SAP HANA provides a range of security features and functions at the database and system
level to ensure secure access control and secure system setup and configuration.

Figure 4: Security Functions Overview
Access Channels
SAP HANA provides standard database interfaces, such as, Java Database Connectivity
(JDBC) and Open Database Connectivity (ODBC), and supports standard SQL with SAP
HANA-specific extensions.
In addition to this channel, the embedded application server available on SAP HANA allows
HTTP(S) access to the database.
For JDBC and ODBC client connections, user passwords are always transmitted in encrypted
hashed form during the user authentication process. The passwords are never transmitted in
plain text.
For HTTP connections, HTTPS can be configured.
In SSO environments, we recommend using encrypted communication channels for all client
connections.
Figure 5: Access Channels

Lesson: Outlining security functions
User Management
Every user who wants to work directly with the SAP HANA database must have a database
user with the necessary privileges. Depending on the situation, the user accessing SAP HANA
may be a technical system user or a user corresponding to a real person.
Figure 6: User Management
A bootstrapping user SYSTEM is created during installation. We recommend the creation of

dedicated administrators and locking the SYSTEM user.
Every tenant database has its own database users, including a tenant database-specific
superuser SYSTEM. User management is managed via SAP HANA or identity management
tools, and provides self services for Web-based password reset, and new user account
requests.
There is automatic locking of users in certain situations (for example, if their validity expired
or they entered a wrong password several times). Manual locking is also possible.
Authentication and Single Sign-on

The SAP HANA database supports a number of authentication mechanisms, including user
name and password, SAML bearer tokens, JSON Web tokens, and Kerberos. Whether a per-
database configuration is possible depends on the authentication mechanism and the user
client.

Figure 7: Authentication and Single Sign-On
The SAP HANA database supports a number of authentication mechanisms, including

database user name/password, SAML bearer tokens, JSON Web tokens, Kerberos, and LDAP
directory server name and password. Whether a per-database configuration is possible
depends on the authentication mechanism and the user client:
● Authentication by database user name and password is database specific.
● For Kerberos-based authentication, a per-database configuration is not possible.
Databases users in all databases must be mapped to users in the same Key Distribution
Center.
● For SAML and JWT-based authentication, a per-database configuration is possible for
JDBC/ODBC client access. Different trust stores (containing different certificates) can be
configured for individual databases. For this purpose, we recommend using certificates
and certificate collections (also referred to as personal security environments or PSEs)
stored in the database as opposed to the file system.
● For LDAP-based authentication, a per-database configuration is possible. Connections to
different LDAP directory servers can be set up by creating separate LDAP providers in
each database. To secure communication between the SAP HANA database and the LDAP
server (including the transmission of passwords), different trust stores (containing
different certificates) can be configured for individual databases using in-memory
certificates and certificate collections.
● Database-specific trust stores cannot be configured for HTTP client access through SAP
HANA Extended Services, classic model (SAP HANA XSC). Therefore, user authentication
based on SAML assertions and X.509 certificates cannot be database specific.
For basic authentication (with user name and password) you can define password policies
(for example, password length and complexity) to enforce password quality.
Password Policy
Passwords for the basic authentication of database users are subject to certain rules. These
rules are defined in the password policy. You can change the default password policy so that it
is in line with your organization's security requirements.

The password policy is defined by parameters in the password policy section of the
indexserver.ini system properties file. Although you can configure your password policy
directly in the indexserver.ini file, it is recommended that you use either the Password Policy
and Blacklist app of the SAP HANA cockpit (available since HANA 1.0 SPS12) or the Security
Editor of the SAP HANA studio.
Authorizations
SAP HANA standard authorization mechanisms are applied to users at the database level.
Several privilege types are used in SAP HANA (system, object, analytic, package, and
application).
Figure 8: Authorizations
The following list outlines some access privileges:

● System privileges control general system activities.
● Object privileges are SQL privileges that are used to allow access to and modification of
database objects.
● Analytic privileges grant different users access to different portions of data in the same
view based on their business role. Within the definition of an analytic privilege, the
conditions that control the data available to users see are either contained in an XML
document, or defined using SQL.
● Package privileges authorize actions on individual packages in the classic (deprecated)
SAP HANA repository.
● Application privileges in (the deprecated) SAP HANA XSC, define the authorization level
required for access to an SAP HANA XSC application (for example, to start the application,
or view particular functions and screens).

Figure 9: Access Privileges in Detail
SAP HANA's standard authorization mechanisms are applied to users at the database level
with the following additions:
● In the system database, the system privilege: DATABASE ADMIN exists to allow system
administrators to perform certain tasks on tenant databases (for example, stop a tenant
database or back up a tenant database).
● A cross-database authorization mechanism exists to support read-only queries between
tenant databases. This is made possible through the association of a user in one tenant
database with a user in another database. Cross-database access is disabled by default
and must be enabled and configured by a system administrator before such user
mappings can be set up.
SAP HANA
Roles
A role is a collection of privileges that can be granted to either a database user or another role
at runtime. A role typically contains the privileges required for a particular function or task.

Figure 10: Role Management
Privileges can be granted directly to users of the SAP HANA database. However, roles are the
standard mechanism of granting privileges as they allow you to implement complex, reusable
authorization concepts that can be modeled on business roles.
Roles bundle privileges for specific groups of users. Role transport available is for DEV, QA,
and PROD system landscapes.
Encryption of Data Communication in the Network

Secure communication based on the Transport Layer Security (TLS)/Secure Sockets Layer
(SSL) protocol can be configured separately for external communication between individual
databases and JDBC/ODBC clients. Separate key and trust stores must be available and
configured for each database. For this purpose, we recommend using certificates and
certificate collections stored in the database as opposed to the file system.
For communication with HTTP clients, a per-database configuration of TLS/SSL keys and
certificates is also possible.

Figure 11: Secure Communication
The three main connection types that can be encrypted are as follows:
● Client to server connections
● Internal connection between SAP HANA components (for example, different SAP HANA
nodes in a scale-out system)
● Connections between data centers (for example, for disaster recovery using SAP HANA
System Replication)
Figure 12: Securing Communication Channels using TLS/SSL
TLS/SSL
TLS/SSL is available for all communication channels, and can be enforced for clients. It
provides automatic setup of key management infrastructure (PKI) for internal
communication channels
Minimal TLS/SSL versions can be configured.

Note:
Certified SAP HANA hosts use a separate network adapter with a separate IP
address for each of the different networks.
Encryption in the Persistence Layer

Data and log volume encryption, as well as data and log backup encryption can enabled for
the system database and tenant databases individually. Data and log volume encryption
ensures that anyone who can access the data and log volumes on disk using operating system
commands cannot see the actual data and redo log entries. Backup encryption prevents
unauthorized parties from reading the content of backups.
Figure 13: Data Encryption
To protect data saved to disk from unauthorized access at operating system level, the SAP
HANA database supports data encryption.
Auditing
Auditing provides you with visibility on what actions were performed in the SAP HANA
database, and when. Actions performed in every tenant database and the system database
can be audited individually.
To ensure the privacy of tenant database audit trails, they are by default written to a database
table that is local to the database being audited. By default, tenant database administrators
cannot change the audit trail targets for their database. The system administrator can change
the audit trail but this is not recommended.
If the audit trail target for tenant databases is changed to the syslog, audit entries contain a
field Database Name so that it is possible to differentiate entries from different tenant
databases.
Although auditing does not directly increase your system's security, it can, if wisely designed,
help you achieve greater security in the following ways:
● Uncover security holes if too many privileges were granted to a user

● Show attempts to breach security

● Protect the system owner against accusations of security violations and data misuse
● Allow the system owner to meet security standards
Figure 14: Audit Logging
Only actions that take place inside the database engine can be audited. If the database engine
is not online when an action occurs, it cannot be detected and therefore cannot be audited.
Audit logging records critical system events

● User management; for example, user changes, role granting
● System access and configuration; for example, failed logons, parameter changes
● Data access; for example, read and write access to tables and views, execution of
procedure
● “Log all”: firefighter logging; for example, for support cases
Audit policies
● Include events to be recorded
● If audit logging is enabled, some critical events are always logged; for example,
disabling of audit logging
Audit trail
● Linux syslog or secure database table
LESSON SUMMARY

Unit 1
Lesson 3
Describing SAP HANA implementation
scenarios
LESSON OBJECTIVES
Describing SAP HANA Implementation Scenarios

SAP traditional security architecture is the standard security architecture that is available
with products such as SAP ERP, SAP BW, or SAP S/4HANA for customer management. The
figure, Traditional Security Architecture, details the security architecture in a typical system
as follows:
Client
Any possible client for the SAP application server. This includes SAP GUI, SAP Business
Client, and SAP Fiori Launchpad.
Application Server
In the common SAP architecture, this is normally the role of SAP Application Server
ABAP or Java. In this case, the SAP HANA platform can also be the application server,
because it can be a database as well as a server for native functionalities and
applications.
Database
SAP HANA is a database at its core, and can be used like any another relational database.
For example, in a classical three-tier deployment, like SAP S/4HANA.

Figure 15: Traditional Security Architecture in SAP Application Server
Nevertheless, SAP HANA can be implemented in different ways, depending on how you want
to use the platform. The different implementation scenarios will determine what you need to
consider from a security perspective.
SAP HANA as Data Mart

In a data mart scenario, data is replicated from a source system, such as, SAP Business
Suite, into the SAP HANA database. Reporting is then carried out on the data in SAP
HANA (for example, using read-only views, dashboards, and so on). Different
architectures can be used in this scenario.
SAP HANA in a Classic Three–Tier Architecture
SAP HANA can be used as a relational database in a classic three-tier architecture (client,
application server, and database).
SAP HANA as a Technical Infrastructure for Native Applications
SAP HANA extended application services (SAP HANA XS), advanced model is the default
framework for native application development on SAP HANA. The SAP HANA extended
application services, classic model (XSC) is the deprecated application development
framework of SAP HANA.

Lesson: Describing SAP HANA implementation scenarios
Figure 16: SAP HANA Implementation Scenarios
SAP HANA as Data Mart

In a data mart scenario, data is replicated from a source system such as SAP Business Suite
into the SAP HANA database. Reporting is then carried out on the data in SAP HANA (for
example, using read-only views, dashboards, and so on). Different architectures can be used
in this scenario.
For example, SAP HANA can be integrated into the SAP BusinessObjects Business
Intelligence (BI) platform as a relational database. The source data can then be analyzed and
reported on by SAP BusinessObjects BI products. Alternatively, SAP HANA can be accessed
directly by BI clients, such as, Microsoft Excel. In this case, end-user clients connect directly
to the database. These architectures are shown in the figure, SAP HANA as Data Mart.
Figure 17: SAP HANA as Data Mart
The implemented architecture determines the extent to which security-related aspects are
handled in SAP HANA. However, user and role management in the database layer of SAP
HANA is required, at least for technical users and administrators. The following text outlines
the relevance of SAP HANA security-related features in this implementation scenario.

User and role management

The extent to which SAP HANA user and role management is required in this scenario
depends on your system architecture as follows:
● If SAP HANA is integrated into a business intelligence solution, for example, SAP
BusinessObjects BI platform, the reporting database, end users, and roles are managed in
the relevant application server. User and role management in the database layer of SAP
HANA is required only for technical database users and administrators.
● If end users connect to the SAP HANA database directly through a SQL client, for example,
SAP BusinessObjects Explorer or Microsoft Excel, user and role management in the
database layer of SAP HANA is required for both end users and administrators.
Authentication and SSO

The extent to which authentication and SSO is handled in SAP HANA depends on your system
architecture in the same way as described above.
● If SAP HANA is used only as the data store, end-user authentication is handled in the
application server. The relevant technical database user accounts are used to authenticate
connections to the database.
● If end users connect to the SAP HANA database directly through a SQL client, the
database user is authenticated. End-user clients support several authentication
mechanisms for integration into SSO environments (SAML, Kerberos, and SAP logon/
assertion tickets).
Authorization
SAP HANA authorization applies to users managed directly in the database.
Auditing
Actions performed in the SAP HANA database can be audited.
SAP HANA in a Classic Three–Tier Architecture

SAP HANA can be used as a relational database in a classic three-tier architecture (client,
application server, and database).
This architecture is depicted in the figure, SAP HANA in a Classic Three-Tier Architecture.

Figure 18: SAP HANA in a Classic Three–Tier Architecture
In this architecture, security-related features, such as, authentication, authorization,

encryption, and auditing, are located and enforced primarily in the application server layer.
The database is used as a data store only. Applications connect to the database using a
technical user, and direct access to the database is only possible for database administrators.
End users do not have direct access to either the database itself or the database server on
which it's running.
As a consequence, security in the database layer is mainly focused on securing administrative
access to the database. Typical examples of this architecture are the SAP S/4HANA and SAP
BW. When SAP HANA is used as a database in these scenarios, the same security approach
applies, and specific SAP HANA security features are mainly needed to control access of
administrators to the database.
The following text outlines the relevance of SAP HANA security-related features in this
implementation scenario.

End users and roles are managed in the application server layer. For example, SAP S/4HANA
applications use the user management and authentication mechanisms of the AS ABAP
platform.
User and role management in the database layer of SAP HANA is required only for technical
database users and administrators.

End-user authentication is handled in the application server layer. The relevant technical
database users are used to authenticate connections to the database.
Administrators with direct access to the database must be authenticated in the database.
Administration clients that access the database through SQL (for example, the SAP HANA
studio and the hdsql command line tool) support the authentication mechanisms Kerberos
and SAP logon/assertion tickets for integration into SSO environments.
Authorization
SAP HANA authorization applies only to technical and administrative database users
managed in the database.

Auditing
SAP HANA as Technical Infrastructure for Native Application Development

SAP HANA extended application services (SAP HANA XS), advanced model is the default
framework for native application development on SAP HANA. The SAP HANA extended
application services, classic model (XCS) is the deprecated application development
framework of SAP HANA.
By default, native SAP HANA applications rely on the security-related features of SAP HANA.
In particular, users of native SAP HANA applications have a corresponding user in the SAP
HANA database.
SAP HANA XS Advanced Model

The SAP XS advanced model provides a comprehensive platform for the development and
execution of native data-intensive applications. XS advanced supports a variety of
programming languages, such as, SQLScript for execution on the data layer, or Java and
node.js for execution in the application server runtime. End-user clients access applications
developed on XS advanced via HTTP(S), while the application runtimes communicate with the
SAP HANA database via SQL.
The architecture of SAP HANA XS advanced (simplified) is depicted in the figure, SAP HANA
as Technical Infrastructure for Native Applications, XS Advanced.
Figure 19: SAP HANA as Technical Infrastructure for Native Applications, XS Advanced
Security and XS Advanced

XS advanced provides deployment flexibility and specific security options.
With XS advanced, the application and database layer can be decoupled. You can either install
XS advanced directly on the SAP HANA server, or install it on a separate host to the SAP
HANA database. This enables you to scale XS advanced independently of the database, as
you can have many more XS advanced hosts than SAP HANA database hosts. You can also
install XS advanced in a separate network from SAP HANA itself, which makes it possible to
put XS advanced applications into a different network zone and have a firewall between the
application and database layers.

XS advanced applications are strictly isolated from each other. They are deployed in
dedicated containers via the SAP HANA deployment infrastructure (HDI) at the database
layer. At the application layer, you can use dedicated operation system users per application.
For more information about secure application development, see the section Maintaining
Application Security in XS Advanced in the SAP HANA Developer Guide for SAP HANA XS
Advanced Model.
Note:
SAP recommends that customers and partners who want to develop new
applications use SAP HANA XS advanced model. If you want to migrate existing
XSC applications to run in the new XS advanced runtime environment, SAP
recommends that you first check the features available with the installed version
of XS advanced; if the XS advanced features match the requirements of the XSC
application you want to migrate, then you can start the migration process. For
more information, see the SAP HANA XS Advanced Migration Guide.
SAP HANA XSC Model

The SAP HANA XSC model embeds a full-featured application server, Web server, and
development environment within SAP HANA. Applications can be developed and deployed
directly on SAP HANA XS, which exposes them to end users through a Web interface.
Note:
2.0 SPS 02. For more information, see SAP Note 2465027. SAP strongly
recommends moving any application to the advanced model.
The architecture of SAP HANA XSC is depicted in the figure, SAP HANA as Technical
Infrastructure for Native Applications, XS Classic.
Figure 20: SAP HANA as Technical Infrastructure for Native Applications, XS Classic

Classic native SAP HANA applications rely on the security-related features of SAP HANA. In
particular, users of native SAP HANA applications must always have a corresponding user in
the SAP HANA database.
The following items outline the relevance of SAP HANA security-related features in this
implementation scenario.

User and roles are managed fully in SAP HANA.

The database user is used to authenticate not only users connecting to the database through
the SQL interface, but also to HTTP clients that connect to SAP HANA XS.
TSeveral mechanisms are supported for the integration of HTTP access through SAP HANA
XS into SSO environments, including SAML, X.509 client certificates, Kerberos with Simple
and Protected GSSAPI Negotiation Mechanism (SPNEGO), and SAP logon/assertion tickets.
Authorization
User access to native SAP HANA applications and applications functions is determined by the
privileges granted to the database user.
Auditing
LESSON SUMMARY

Unit 1
Learning Assessment
1. SAP HANA is an in-memory platform, which is used for performing real-time analytics,
and for developing and deploying real-time applications.
Determine whether this statement is true or false.
X True
X False
2. You want system settings to be set so that users are only able to view and perform actions
required to fulfill their tasks. Which security function provides this?
Choose the correct answer.
X A Authentication
X B Authorization
X C Audit logging
X D Encryption
3. Which of the following are part the implementation scenario for a native two-tier
application?
Choose the correct answers.
X A Client
X B XS Application Server
X C SAP ABAP Application Server
X D BI Server
X E SAP HANA

Unit 1
Learning Assessment - Answers
1. SAP HANA is an in-memory platform, which is used for performing real-time analytics,
and for developing and deploying real-time applications.
X True
X False
This is correct! SAP HANA is an in-memory platform, which is used for performing real-
time analytics, and for developing and deploying real-time applications.
2. You want system settings to be set so that users are only able to view and perform actions
required to fulfill their tasks. Which security function provides this?
X A Authentication
X B Authorization
X C Audit logging
X D Encryption
This is correct! The security function you are referring to is Authorization.
3. Which of the following are part the implementation scenario for a native two-tier
application?
X A Client
X B XS Application Server
X C SAP ABAP Application Server
X D BI Server
X E SAP HANA
Correct. Client, XS Application Server, and SAP HANA are part of the implementation
scenario for a native two-tier application.

UNIT 2 Using SAP HANA
administration tools
Lesson 1
Using security administration tools 31
UNIT OBJECTIVES
● Use security administration tools

Unit 2: Using SAP HANA administration tools

Unit 2
Lesson 1
Using security administration tools
LESSON OBJECTIVES
Using Security Administration Tools
Figure 21: Security Administration: When to Use What
SAP HANA Cockpit is the native tool for SAP HANA database administration. It can be used
for administration and monitoring of SAP HANA databases, including system configuration,
user management, and performance monitoring capabilities.
SAP HANA Cockpit is a Web-based tool that is built on SAP HANA XS Advanced to leverage
the latest SAP technology. It allows faster delivery and new innovations. SAP HANA Cockpit is
a single Web console that simplifies the administration for landscape, group, and individual
SAP HANA databases.
SAP HANA Cockpit provides an overview of important security KPIs. It allows easy access to
the security configuration.
SAP HANA HDBSQL

SAP HANA HDBSQL allows you to execute SQL statements and database procedures, as well
as query information about the database and catalog objects, from the command line.
SAP HANA hdbsql is a command line tool installed on the SAP HANA server. It is available
at /usr/sap/<SID>/HDB<instance>/exe. It can be used to access databases on both
local and remote computers.

SAP Solution Manager

The following considerations apply to SAP Solution Manager:
● Use SAP Solution Manager for end-to-end root cause analysis and a unified alert inbox for
the entire landscape and for business process reporting.
● SAP Solution Manager has a central alerting and monitoring infrastructure.
● It runs on AS ABAP-based SAP systems.
SAP DBA Cockpit

The DBA Cockpit is a platform-independent tool provided by AS ABAP-based SAP systems,
which you can use to monitor and administer your SAP HANA database.
SAP Landscape Management

The following considerations apply to SAP Landscape Management:
● Use SAP Landscape Management for automating advanced SAP HANA operations and to
avoid business downtime during maintenance activities.
● SAP Landscape Management is a central landscape management solution, running on AS
Java-based SAP systems.
Integration with SAP Security Tools and Services
Figure 22: Integration with SAP Security Tools and Services
SAP HANA can be integrated with SAP security tools and services. Information gathered from
SAP Solution Manager is used to develop a set of services to help ensure secure configuration
during initial system setup. On the one hand, the security specific information in the SAP
EarlyWatch Alert service and the more detailed security optimization services (SOS) compare
customer settings (configurations and critical basis authorizations) with SAP- recommended
standards. The overall goal of these tools is to compare customer systems to the SAP
security recommendations.
The following list is a basic description of these tools and services:

Lesson: Using security administration tools
SAP Early Watch Alert (EWA)

● SAP EarlyWatch Alert is an important factor in ensuring that your core business
processes work. It is a tool that monitors the essential administrative areas of SAP
components and keeps you up to date on their performance and stability. SAP
EarlyWatch Alert runs automatically to keep you informed, so you can react to issues
proactively before they become critical.
● Alerts indicate critical situations and give solutions to improve performance and
stability.
● This analytics tool is based on experience with thousands of installations giving you a
tool to save time, reduce costs, and keep your SAP solution running smoothly.
Security Optimization Service (SOS)

● This service provides a detailed security assessment on critical configurations and
authorizations.
● It comprises a system analysis and the resulting recommendations for system
settings with only data collection/read-access to the system to be analyzed.
Therefore, it can be used to analyze critical production systems without endangering
their operation.
System Recommendations
● These are detailed recommendation of SAP notes which should be implemented
based on the actual status of the system and previously implemented notes.
Configuration Validation
● The Configuration Validation checks if the customer systems adhere to the customer-
specific security policies.
● It provides reporting on how homogeneous security system is.
● The Configuration Validation uses centrally stored configuration data in Solution
Manager to validate a large number of systems using a subset of the collected
configuration data.
Security in the Monitoring and Alerting Infrastructure

● Utilize the Monitoring and Alerting Infrastructure (MAI) in SAP Solution Manager for
security.
● Respond to identified security-relevant events or situations, based on EarlyWatch
Alert findings, dedicated configuration validation target systems, security audit log,
and input from additional sources.
Based on these checks, a customer-specific security baseline can be derived that also takes
into account customer-specific conditions and security regulations. Any changes during
operations can subsequently be monitored with the help of change diagnostics and be
compared against this customer-specific security baseline using configuration validation, to
help ensure that unwanted change are noticed.
On top of regular monitoring, SAP advises running the complete set of reports from SOS or
SAP EarlyWatch Alert periodically to help ensure compliance of the landscape.

Figure 23: Overview: SAP HANA Cockpit
SAP HANA cockpit provides a single point of access to a range of tools for administration and
detailed monitoring of SAP HANA databases. It also integrates SQL development capabilities
required by administrators. SAP HANA cockpit provides aggregate, system, and tenant
database administration features (for example, database monitoring, user management, and
data backup).
Administrators can use the SAP HANA Cockpit to start and stop services, to monitor the
system, to configure system settings, and to manage users and authorizations.
Initially, the SAP HANA cockpit displays data at a landscape or enterprise level. You can
quickly drill down to an overview of an individual database. Links, data, cards, and different
parts of a single card are drillable, providing access to more detailed information and
functions.
Figure 24: Security Management in SAP HANA Cockpit

Lesson: Using security administration tools
SAP HANA cockpit provides several security related cards with an overview of the important
security KPIs during operation of your system and allows easy access to the security
configuration.
From SAP HANA cockpit, you can manage, administer configure, and monitor SAP HANA
database systems as for the following security areas:
● User and role management
● Management of privileges
● Management of audit policies
● Configuration of password policies
● Certificate management
Within the Database Overview app, you can choose the Security and User Management view
on the top left corner, to filter down to the main security related cards.
Figure 25: User Management in SAP HANA Cockpit
As an example, in SAP HANA Cockpit you can perform user management tasks and assign
roles to users. To achieve this, in the Database Overview app of your system or tenant
database, search for the User & Role Management card and choose the Role Assignment link.
LESSON SUMMARY


Unit 2
Learning Assessment
1. In SAP HANA, user management can be delegated to an ABAP system.

X True
X False
2. SAP HANA only allows a user to log on using a user and password as the authentication
method.
X True
X False
3. SAP HANA includes a specific functionality: Audit Log, to track the activities performed by
the users.
X True
X False

Unit 2
1. In SAP HANA, user management can be delegated to an ABAP system.

X True
X False
This is correct. In SAP HANA, user management cannot be delegated to an ABAP system.
2. SAP HANA only allows a user to log on using a user and password as the authentication
method.
X True
X False
This is correct. Various methods are available.
3. SAP HANA includes a specific functionality: Audit Log, to track the activities performed by
the users.
X True
X False
This is correct. Audit Log is available in SAP HANA, so that you can track the activities
performed by users.

UNIT 3 Managing users
Lesson 1
Comparing User Types 41
Lesson 2
Managing User Groups 47
Lesson 3
Describing User Administration Tools 53
UNIT OBJECTIVES
● Compare the different user types in SAP HANA

● Manage user groups
● Create Users

Unit 3: Managing users

Unit 3
Lesson 1
Comparing User Types
LESSON OBJECTIVES
User Types
Every user who wants to work with the SAP HANA database must have a database user. As a
user administrator, you create and provision the required users, as well as perform other
tasks related to user administration.
User Management Tasks
● Creating roles and users

● Granting users the roles and privileges they require for their duties
● Other user administration tasks, such as, resolving authorization or authentication issues,
deactivating users, and so on.
● Configuring SAP HANA for the required user authentication mechanisms
Note:
Users of SAP HANA SAP HANA Extended Services (SAP HANA XS) advanced
applications are managed independently of the SAP HANA database. Dedicated
administration tools are available for managing application users and roles.
It is often necessary to specify different security policies for different types of database user.
In the SAP HANA database, we differentiate between database users that correspond to real
people, and technical database users.
● Database users that correspond to real people
The database administrator creates a database user for every person who works in the
SAP HANA database. Database users that correspond to real people are dropped when the
person leaves the organization. This means that the database objects they own are also
automatically dropped, and privileges they granted are automatically revoked.
● Technical database users
Technical database users do not correspond to real people, they are not dropped if a
person leaves the organization. Therefore, you can use them for administrative tasks, such
as, creating objects and granting privileges for a particular application. Some technical
users are available as standard, for example, users SYS and _SYS_REPO. Other technical

database users are created for application-specific purposes. For example, an application
server can log on to the SAP HANA database using a dedicated technical database user.
Technically, these user types are the same. The only difference between them is conceptual.
Database users that correspond to real people can be grouped according to different tasks.
Note:
For a complete overview of the technical users of the SAP HANA database, see the
SAP HANA Security Guide.
Database Users that Correspond to Real People

Every person who needs to work with SAP HANA must have a database user. Depending on
your system configuration and scenario, database users can be created by:
● User administrators
● User group administrators
● An LDAP provider used for user authentication and enabled for automatic user creation
Database users that correspond to real people are dropped when the person leaves the
organization. This means that any database objects that they own are also automatically
dropped, and any privileges that they granted are automatically revoked.
Note:
Database users created by an LDAP provider must be dropped manually by a user
administrator. If the user is dropped on the LDAP server, the corresponding
database user in SAP HANA is not automatically dropped.
Database users are created with either the CREATE USER or CREATE RESTRICTED USER
statement, or using SAP HANA cockpit (User Management).
User Access Channels

Users can connect to SAP HANA through JDBC or ODBC, or through HTTP/S.
The protocol for database client access (SQLDBC [ODBC/JDBC]) is used in the following
scenarios:
● Application servers that use SAP HANA as a database
● End-user clients that access the SAP HANA database directly
● SAP HANA cockpit
HTTP/S client access is used for a connection between a Web browser or mobile device and
applications based on SAP HANA extended application services.

Lesson: Comparing User Types
Figure 26: Access Channels for Users
Note:
To find out which users can connect via JDBC/ODBC, you can check the column
IS_CLIENT_CONNECT_ CONNECT_ENABLED = TRUE in the USERS system view.
User Types in SAP HANA

Database users are created as either standard users or as restricted users.
Standard users correspond to users created with the CREATE USER statement. By default
they can create objects in their own schema and read data in system views. Read access to
system views is granted by the PUBLIC role, which is granted to every standard user.
Restricted users, which are created with the CREATE RESTRICTED USER statement, initially
have no privileges. Restricted users are intended for provisioning users who access SAP
HANA through client applications and who are not intended to have full SQL access via an
SQL console. If the privileges required to use the application are encapsulated within an
application-specific role, then it is necessary to grant the user only this role. In this way, it can
be ensured that users have only those privileges that are essential to their work.

Figure 27: Different User Types
Compared to standard database users, restricted users are initially limited in the following
ways:
● They cannot create objects in the database as they are not authorized to create objects in
their own database schema.
● They cannot view any data in the database as they are not granted the standard PUBLIC
role.
● They are only able to connect to the database using HTTP/HTTPS.
Note:
Disabling ODBC/JDBC access for a user, either a restricted user or a standard
user, does not affect the user's authorizations or prevent the user from executing
SQL commands via channels other than JDBC/ODBC. If the user has been
granted SQL privileges (for example, system privileges and object privileges), they
are still authorized to perform the corresponding database operations using, for
example, a HTTP/HTTPS client.
Technical Database Users

Technical database users do not correspond to real people. They are therefore not dropped if
a person leaves the organization. This means that they should be used for administrative
tasks, such as, creating objects and granting privileges for a particular application.
Some technical users are available as standard, for example:
● SYS
This is an internal database user. It is the owner of database objects, such as, system
tables and monitoring views.
● _SYS_AFL
This is an internal user that owns all objects for application function libraries.
● _SYS_EPM
This is an internal database user used by the SAP Enterprise Performance Management
(SAP EPM) application.

Lesson: Comparing User Types
● _SYS_STATISTICS
This is an internal database user used by the internal monitoring mechanism of the SAP
HANA database. It collects information about status, performance, and resource usage
from all components of the database and issues alerts if necessary.
Figure 28: Technical Database Users
Other technical database users are created for application-specific purposes. For example, an
application server may log on to the SAP HANA database using a dedicated technical
database user.
Technical users are standard users created with the CREATE USER statement.
LESSON SUMMARY


Unit 3
Lesson 2
Managing User Groups
LESSON OBJECTIVES
Managing User Groups

User groups allow you to manage related users together. Group administrators can be
assigned to manage individual user groups exclusively and independently of each other.
Figure 29: User Groups
In the example scenario shown in the figure, User Groups, the user groups were set up for
exclusive administration. Only the group admins for the restricted user group Sales can
create or delete users in this user group and manage security properties of the Sales users.
The Sales group admins can only manage users of the Sales group, but not users from other
user groups like Research or Training.
User groups are an efficient way to manage users:
● Every user group can have its own dedicated administrator(s). In this way, user
management tasks can be delegated to several people independently of each other.
● A user group can be configured for exclusive administration, which means that only the
designated group administrator(s) can manage the users in the group. This could be
useful, for example, to protect highly-privileged users or technical users from accidental
deletion or manipulation.

● Group specific-user configuration is possible. By setting user properties at the group level,
you can configure related users quickly and differently to users in other groups. For
example, you could put the technical users required by connecting applications into their
own user group with a customized password policy so that the passwords of these users
are extra complex.
Caution:
User groups do not control data access. They are intended to support a
separation of user management duties. A users authorization (roles and
privileges) controls data access.
Figure 30: User Groups: How Do they Relate to Roles and Authorization?
Create User Groups

A global user administrator (that is, a user with system privilege USER ADMIN) creates user
groups using the CREATE USERGROUP statement. The user administrator can then designate
one or more group administrators by granting the object privilege USERGROUP OPERATOR
on the user group to the relevant user.
Note:
A user can be the group administrator of more than one group.
The USERGROUP OPERATOR privilege authorizes a user to change the settings for a user
group, and to add and remove users to/from a user group. Users with the USERGROUP
OPERATOR privilege can also create and drop users, but only within the user group on which
they have the USERGROUP OPERATOR privilege (CREATE USER <user_name> SET
USERGROUP <usergroup_name>).

Lesson: Managing User Groups
Note:
A user can have the USERGROUP OPERATOR privilege on more than one user
group, and a user group can have more than one user with the USERGROUP
OPERATOR privilege on it.
Figure 31: Create User Groups in SAP HANA Cockpit
User administrators can also specify the administration "mode" of the user group. This
determines who can administer the group:
● Group administrators and user administrators (shared administration)
Not only designated group administrators can modify the group but also any user
administrator (that is, any user with system privilege USER ADMIN).
This is the default administration mode.
● Group administrators only (exclusive administration)
Only the designated group administrator(s) can modify the group, for example, adding
new users to the group or removing users from the group. In this way, groups of users can
be managed completely independently of each other.
Note:
To add an existing user from the global pool of users to the user group, as well as
remove a user from the group (and return it to the global pool of users), the group
administrator also needs to be a user administrator, that is have system privilege
USER ADMIN.
The user administrator can configure the administration mode when creating the group, or
later by editing the group. The authorization mode is configured with the option ENABLE |
DISABLE USER ADMIN of the CREATE USERGROUP and ALTER USERGROUP statements as
follows:

Figure 32: Create User Groups Using SQL Commands
If the user group is configured for exclusive administration, only the designated group
administrator(s) can modify the group, for example, adding new users to the group or
removing users from the group. In this way, groups of users can be managed independently of
each other.
Note:
A user can belong to only one user group, but a user does not have to be a
member of any group. Users who are not in any group are managed as normal by
user administrators.
To move a user from one group to another, a user authorized for both user groups simply add
the user to the new user group with the ALTER USER <username> SET USERGROUP
<usergroupname>. This automatically removes the user from the original user group.
Parameter Set for User Groups

In addition to grouping users into meaningful categories, user groups also allow you to mass
manage certain user parameters. In this way, you can configure all users in a user group not
only quickly but differently to users in other groups.
There are two steps to configuring users with user groups:
● Configuring the group-specific values of parameters
● Enabling the parameter set to which the configured parameters belong so that they take
effect
Similarly to the configuration of authorization mode, the user parameters can be configured
when the user group is created or by editing the group later.
To see the group-specific values of parameters, query the USERGROUP_PARAMETERS view.
Base Setup for User Groups

You can use a wizard to quickly apply a basic configuration for user groups. Instead of
manually configuring user groups, you can use a wizard to apply SAP's recommended
configuration settings. This allows you to quickly start working with user groups.
For a registered database, the UI notifies you if user group configuration was not completed
using the base setup wizards. You have the option to disable these notifications.

Lesson: Managing User Groups
Figure 33: Create User Groups: Base Setup
Note:
The base setup does not guarantee that the configuration is optimal for your
particular system. To optimize the configuration, it may be advisable to manually
configure specific settings.
USERGROUPS System View

You can find information about user groups in the USERGROUPS system view.
Figure 34: USERGROUPS System View
LESSON SUMMARY


Unit 3
Lesson 3
Describing User Administration Tools
LESSON OBJECTIVES
● Create Users
Manage Users
Native User Management Tasks
Tasks for provisioning users in SAP HANA
1. Define and create roles.
2. Define and create user groups.
3. Create users in user groups.
4. Grant roles to users.
Further administration tasks:
● Deleting users
● Reactivating users after too many failed logon attempts
● Deactivating users if a security violation has been detected
● Resetting user passwords
The following table provides an overview of who does which of these tasks and the SAP HANA
tools available:
Table 1: Overview on user administration tasks

Job Function Task Tool
Role designer or creator Create roles and role hierar- ● SAP HANA XS advanced:
chies that reflect the access SAP Web IDE for SAP HA-
requirements, job function, NA
and responsibilities of system
user ● SAP HANA XS classic:
SAP HANA Web-based
Development Workbench
Application developer Create roles for new applica- SAP HANA XS classic: SAP
tions developed on SAP HA- HANA Web-based Develop-
NA XS classic ment Workbench


User administrator Create user groups SAP HANA cockpit
Create SAP HANA database
users in user groups
Grant roles to database users
Delete, deactivate, and reac-
tivate database users
Reset user passwords
Note:
SAP HANA XS advanced has the additional concept of application roles and role
collections. These are independent of database roles in SAP HANA itself. In the XS
advanced context, SAP HANA database roles are used only to control access to
database objects (for example, tables, views, and procedures) for XS advanced
applications. For more information about the authorization concept of XS
advanced.
SAP HANA Cockpit
SAP HANA Cockpit

All the user management tasks can also be performed from the user management application
in SAP HANA Cockpit.
You can create a standard database user for every person who works directly with the SAP
HANA database. When you create a user, you also configure how the user is authenticated.
Figure 35: Creating Named Users using SAP HANA Cockpit

Lesson: Describing User Administration Tools
When you create a user, specify the following properties:

● General Information
- User Name
Enter a unique user name.
- Optional: User Group
Enter the user group assigned to the user.
- Optional: E-mail address
Enter the user's e-mail address.
- Optional: Validity Period, including the appropriate time zone
Enter the validity period of the user. If the user account is not currently within its validity
period, the user is inactive and cannot log on. If no validity period is configured, the user
is indefinitely valid.
- Optional: Creation of Objects in Own Schema
Prevent the user from being able to create objects in his own database schema.
- Optional: PUBLIC Role.
Prevent the user from being granted the standard PUBLIC role.
The PUBLIC role contains the privileges for filtered read-only access to the system
views. To see data in a particular view, the user also needs the SELECT privilege on the
view.
- Optional: Disable ODBC or JDBC Access.
This indicates whether or not the user can connect to the database via ODBC or JDBC.
By default, ODBC and JDBC access is enabled for standard users and is disabled for
restricted users. This means that restricted users can only connect via HTTP or HTTPS.
- Optional: Comment
Enter a comment.
- Optional: Set the authorization mode to LDAP if the user's authorization is based on
LDAP group membership-
- Specify how the user can be authenticated
You can configure additional user properties for client applications. The following custom user
properties are available by default:
● LOCAL
This is the user's locale.
● PRIORITY
This is the priority with which the thread scheduler handles statements executed by the
user. The priority can be in the range 0-9, with 9 representing the highest priority. 5 is the
default priority.
● STATEMENT MEMORY LIMIT

This is the maximum memory (in GB) that can be used by a statement executed by the
user.
● STATEMENT THREAD LIMIT
This is the maximum number of threads that can be used by a statement executed by the
user.
● TIME ZONE
This is the user's time zone. The standard database formats for locale and time zone are
supported.Local
SQL Commands
Another option is to perform all the administration tasks using SQL commands.
Figure 36: Creating Users Using SQL
More details about the additional options and parameters available in the command can be
found in the SAP HANA SQL and System Views Reference guide, available at http://
help.sap.com/hana_platform.
Convert User Types

A user administrator can convert a restricted user into a standard user (or vice versa) as
follows:

Figure 37: Convert User Types
Note:
A user is only identified as a restricted user in system view USERS if he doesn't
have the PUBLIC role or authorization for his own schema.
Create users in User Maintenance Transaction of an AS ABAP based SAP-System

In a typical AS ABAP based SAP-system installation, you maintain users who execute
applications on the AS ABAP in transaction SU01. There, you can also maintain several
technical users for the DBMS, but this is only required in certain specific use cases.
● For SAP Business Warehouse (SAP BW), a 1:1 assignment of users is required to grant
analytics permissions in the database to virtual analysis users in SAP BW.
● Users run applications that access the database directly. You have to assign database
authorizations to these users.
When your SAP system is running on SAP HANA DB, to simplify DMBS user administration,
you can define a connection between user administration in AS ABAP and the DBMS. When
you create users in AS ABAP, users in the DBMS are created automatically with the same
user IDs and the same passwords. When an administrative lock is set for a user in AS ABAP,
the corresponding DBMS user is also locked. You can also add or remove DBMS
authorizations for the DBMS user, as long as the DBMS supports this.
Note:
Password synchronization and password locks are not supported.
Hint:
This customizing is client-specific.
Only customize one ABAP client. The same user ID on different ABAP clients can
represent different users with different authorizations. It is not good practice to
map them to the same DBMS user.

Figure 38: SU01: DBMS User Management
Hint:
The option to synchronize users created with transaction SU01 in ABAP with the
SAP HANA database, must be configured first.
Configuring DBMS User Management for SAP HANA

1. Created a database user in SAP HANA with the following attributes:
System Privilege: USER ADMIN

System Privilege: ROLE ADMIN
System Privilege: CATALOG Read
Object Privilege: EXECUTE on the procedure GRANT_ACTIVATED_ROLE
Object Privilege: EXECUTE on the procedure REVOKE_ACTIVATED_ROLE
● The database user must log on with user name and password.
● The database user has a productive password.
2. Add a database connection in table DBCON with Change View "Description of Database
Connections": Overview (transaction DBCO) for the database user and database type HDB.
3. Enter the name of the database connection and the client in the USR_DBMS_SYSTEM view
with Maintain Table View (transaction SM30).

User Administration Tools - Overview

Depending on your organization and its user provisioning strategy, people with different job
functions may be involved in the process of user administration. Different tools are used for
different tasks.
● Native SAP HANA User Administration
Allows you to perform the management task manually using SQL commands or client tools
like SAP HANA Cockpit.
● LDAP-Compliant Identity Management Server
LDAP-compliant directory server can be used to manage users and their access to
resources.
● SAP NetWeaver Identity Management
SAP NetWeaver Identity Management contains a connector to the SAP HANA database.
● AS ABAP - User Maintenance
Transaction SU01 of an AS ABAP based SAP-system allows creation of users in the SAP
HANA database and the assignement of roles.
● SAP HANA Lifecycle Management Tool hdblcm(gui)
You can use the SAP HANA lifecycle management tools to perform post-installation steps
including changing the passwords of the system database user SYSTEM and operating
system administrator <sid>adm as part of system rename.
● SAP Access Control
SAP Access Control 10.1 can be used to manage access and risk analysis for SAP HANA-
based authorizations.
Figure 39: Create and Manage Users

Note:
To perform user management tasks the system privilege USER ADMIN is
required.
SAP HANA Lifecycle Management Tool hdblcm(gui)

You can use the SAP HANA lifecycle management tools to perform post-installation steps
including changing the passwords of the system database user SYSTEM and operating
system administrator <sid>adm as part of system rename. For more information, see the
SAP HANA Administration Guide.
Integration into Other Identity Management Tools

LDAP-Compliant Identity Management Server
The Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing
directory services. If you use an LDAP-compliant directory server to manage users and their
access to resources, you can leverage LDAP-based authentication to access SAP HANA and
LDAP group membership to authorize users. With LDAP-based authentication, users can be
automatically provisioned in SAP HANA.
Note:
Currently, authorization and authentication with OpenLDAP is only supported for
Active Directory.
SAP NetWeaver Identity Management

SAP NetWeaver Identity Management 7.2 Support Package Stack (SPS) 3 and higher
contains a connector to the SAP HANA database. With SAP NetWeaver ID Management you
can perform several user administration tasks in the SAP HANA database, including:
● Creating and deleting user accounts
● Granting roles
● Setting passwords for users
To use the SAP HANA connector for SAP NetWeaver ID Management, a dedicated SAP HANA
database user must be created with the following roles and privileges:
● Standard role MONITORING
● System privilege ROLE ADMIN and USER ADMIN
● Object privilege EXECUTE on the procedure GRANT_ACTIVATED_ROLE
Create Users
Native User Management Tasks
Tasks for provisioning users in SAP HANA
1. Define and create roles
2. Define and create user groups

3. Create users in user groups
4. Grant roles to users
Further administration tasks:
● Deleting users
● Reactivating users after too many failed logon attempts
● Deactivating users if a security violation has been detected
● Resetting user passwords
The following table provides an overview of the users assigned to the tasks and the SAP
HANA tools available:
Table 2: Overview on user administration tasks

Role designer or creator Create roles and role hierar- ● SAP HANA XS advanced:
chies that reflect the access SAP Web IDE for SAP HA-
requirements, job function, NA
and responsibilities of system
user ● SAP HANA XSC: SAP HA-
NA Web-based Develop-
ment Workbench
Application developer Create roles for new applica- SAP HANA XSC: SAP HANA
tions developed on SAP HA- Web-based Development
NA XSC Workbench
User administrator Create user groups SAP HANA cockpit
Create SAP HANA database
users in user groups
Grant roles to database users
Delete, deactivate, and reac-
tivate database users
Reset user passwords
Note:
SAP HANA XS advanced has the additional concept of application roles and role
collections. These are independent of database roles in SAP HANA itself. In the XS
advanced context, SAP HANA database roles are used only to control access to
database objects (for example, tables, views, and procedures) for XS advanced
applications. For more information about the authorization concept of XS
advanced.

SAP HANA Cockpit

All the user management tasks can also be performed from the user management application
in SAP HANA Cockpit.
You can create a standard database user for every person who works directly with the SAP
HANA database. When you create a user, you also configure how the user is authenticated.
Figure 40: Creating Named Users using SAP HANA Cockpit
When you create a user, specify the following properties:

● General Information
- User Name
Enter a unique user name.
- Optional: User Group
Enter the user group assigned to the user.
- Optional: E-mail address
Enter the user's e-mail address.
- Optional: Validity Period, including the appropriate time zone
Enter the validity period of the user. If the user account is not currently within its validity
period, the user is inactive and cannot log on. If no validity period is configured, the user
is indefinitely valid.
- Optional: Creation of Objects in Own Schema
Prevent the user from being able to create objects in his own database schema.
- Optional: PUBLIC Role.
Prevent the user from being granted the standard PUBLIC role.

The PUBLIC role contains the privileges for filtered read-only access to the system
views. To see data in a particular view, the user also needs the SELECT privilege on the
view.
- Optional: Disable ODBC or JDBC Access.
This indicates whether or not the user can connect to the database via ODBC or JDBC.
By default, ODBC and JDBC access is enabled for standard users and is disabled for
restricted users. This means that restricted users can only connect via HTTP or HTTPS.
- Optional: Comment
Enter a comment.
- Optional: Set the authorization mode to LDAP if the user's authorization is based on
LDAP group membership.
- Specify how the user can be authenticated.
You can configure additional user properties for client applications. The following custom user
properties are available by default:
● LOCAL
This is the user's locale.
● PRIORITY
This is the priority with which the thread scheduler handles statements executed by the
user. The priority can be in the range 0-9, with 9 representing the highest priority. 5 is the
default priority.
● STATEMENT MEMORY LIMIT
This is the maximum memory (in GB) that can be used by a statement executed by the
user.
● STATEMENT THREAD LIMIT
This is the maximum number of threads that can be used by a statement executed by the
user.
● TIME ZONE
This is the user's time zone. The standard database formats for locale and time zone are
supported.
SQL Commands
Another option is to perform all the administration tasks using SQL commands.

Figure 41: Creating Users Using SQL
More details about the additional options and parameters available in the command can be
found in the SAP HANA SQL and System Views Reference guide, available at http://
help.sap.com/hana_platform.
Convert User Types

A user administrator can convert a restricted user into a standard user (or vice versa) as
follows:
Figure 42: Convert User Types
Note:
A user is only identified as a restricted user in system view USERS if he doesn't
have the PUBLIC role or authorization for his own schema.

Create users in User Maintenance Transaction of an AS ABAP based SAP-System

In a typical AS ABAP based SAP-system installation, you maintain users who execute
applications on the AS ABAP in transaction: SU01. There, you can also maintain several
technical users for the DBMS, but this is only required in certain specific use cases.
● For SAP Business Warehouse (SAP BW), a 1:1 assignment of users is required to grant
analytics permissions in the database to virtual analysis users in SAP BW.
● Users run applications that access the database directly. You have to assign database
authorizations to these users.
When your SAP system is running on SAP HANA DB, to simplify DMBS user administration,
you can define a connection between user administration in AS ABAP and the DBMS. When
you create users in AS ABAP, users in the DBMS are created automatically with the same
user IDs and the same passwords. When an administrative lock is set for a user in AS ABAP,
the corresponding DBMS user is also locked. You can also add or remove DBMS
authorizations for the DBMS user, as long as the DBMS supports this.
Note:
Password synchronization and password locks are not supported.
Hint:
This customizing is client-specific.
Only customize one ABAP client. The same user ID on different ABAP clients can
represent different users with different authorizations. It is not good practice to
map them to the same DBMS user.

Figure 43: SU01: DBMS User Management
Hint:
The option to synchronize users created with transaction: SU01 in ABAP with the
SAP HANA database, must be configured first.
Configuring DBMS User Management for SAP HANA

1. Created a database user in SAP HANA with the following attributes:
System Privilege: USER ADMIN

System Privilege: ROLE ADMIN
System Privilege: CATALOG Read
Object Privilege: EXECUTE on the procedure GRANT_ACTIVATED_ROLE
Object Privilege: EXECUTE on the procedure REVOKE_ACTIVATED_ROLE
● The database user must log on with user name and password.
● The database user has a productive password.
2. Add a database connection in the DBCON table with Change View "Description of
Database Connections": Overview (transaction DBCO) for the database user and database
type HDB.
3. Enter the name of the database connection and the client in the USR_DBMS_SYSTEM view
with Maintain Table View (transaction SM30).

LESSON SUMMARY
● Create Users


Unit 3
Learning Assessment
1. In SAP HANA, which two of the following types of user exist?

X A Power users
X B Standard users
X C Technical users
X D Restricted users
2. User groups are used to control data access (authorizations).

X True
X False
3. Which of the following options can be used for user management in SAP HANA?
X A SAP HANA Cockpit
X B DBA Cockpit
X C SQL command
X D SAP Netweaver IDM

Unit 3
1. In SAP HANA, which two of the following types of user exist?

X A Power users
X B Standard users
X C Technical users
X D Restricted users
This is correct. Standard and Restricted users exist.
2. User groups are used to control data access (authorizations).

X True
X False
That is correct. User groups are designed to provide separation of duties for user
management.
3. Which of the following options can be used for user management in SAP HANA?
X A SAP HANA Cockpit
X B DBA Cockpit
X C SQL command
X D SAP Netweaver IDM
This is correct. SAP HANA Cockpit, SAP HANA Netweaver IDM, and SQL commands can
be used for user management in SAP HANA.

UNIT 4 Implementing authorizations in
the SAP HANA Database
Lesson 1
Describing object ownership rules 73
Lesson 2
Introducing Authorizations in the SAP HANA Database 79
Lesson 3
Introducing database roles management 89
Lesson 4
Creating Catalog Roles 93
Lesson 5
Creating HDI roles 99
Lesson 6
Comparing Role Types 109
UNIT OBJECTIVES
● Describe object ownership rules and effects

● Describe the basic authorization concepts of the SAP HANA database
● Describe the role concept of the SAP HANA database
● Define, create and manage catalog roles
● Create HDI roles
● Create HDI Roles to access database objects located in a different SAP HANA instance or
schema
● Compare role types

Unit 4: Implementing authorizations in the SAP HANA Database

Unit 4
Lesson 1
Describing object ownership rules
LESSON OBJECTIVES
Describing Object Ownership Rules

Before we can manage authorizations in SAP HANA, it is important to understand the basic
ownership concept for database objects, such as, tables or schemas, and the implications of
this concept.
The owner of an object is the user who creates the object. Generally speaking, only the object
owner can initially access the object and grant object privileges to other users. However, all
objects are located in a schema and the schema itself it is an object with an owner. The
schema owner may be different to the owners of objects contained within the schema.
Figure 44: Understand Database Terminology
In the figure, Owner Versus Schema: How SAP HANA Handles Ownership of Catalog Objects,
we can see the following example:
● User BILL owns the schema BILL and the schema WDF.
● User JIM owns the schema JIM.
● As the owners can grant privileges to others, user BILL grants user JIM the privilege to
create objects over schema BILL.

● User JIM creates the table ORDERS inside schema BILL (table name = BILL.ORDERS).
Figure 45: Owner Versus Schema: How SAP HANA Handles Ownership of Catalog Objects
Based on our example, we need to understand which objects can be accessed by the relevant
users. The following object ownership rules dictate who can access objects:
● The owner of the object
● The owner of the schema in which the object is located
● Users to whom the owner of the object has granted privileges
● Users to whom the owner of the parent schema has granted privileges
Taking this into consideration, we can conclude that user BILL can only access schema JIM
and the table BILL.ORDERS. On the other hand, user BILL has access to schema WDF and
schema BILL. Notice that user BILL also has access to all the content of those schemas, and
therefore, user BILL also has access to table BILL.ORDERS.
Let's look at the implications of the ownership concept in the case where one of the users
needs to be dropped. The following rules apply:
● You can only drop a user if they own no objects (except their own schema).
● If the user owns further objects, the only option is to drop the user with the “cascade”
option. This means that all the objects owned by the user are dropped and all the privileges
on these objects are revoked.
● If one of the objects of the user that is going to be dropped is a schema, all the objects
located in that schema are also dropped (even if they are owned by a different user).

Lesson: Describing object ownership rules
Figure 46: Dropping of DB Users: The Impact of Dropping with Cascade
Returning to our example, let us analyze what would happen if we drop each of the users. The
following rules apply:
● In both cases we need to use the cascade option as both users own other objects beside
their own schema.
● If we drop user JIM with the “cascade” option, the schema JIM and the table BILL.ORDERS
are also dropped.
● If we drop user BILL with the “cascade” option, the schema WDF and its content (table
WDF.SALES) are dropped. Also, the schema BILL and the table BILL.ORDERS (owned by
JIM) are dropped.
The deletion of users also has an impact on the privileges that the user granted to others.
When a user is dropped, all the privileges granted by the user to others (users or roles) are
also revoked.
When we drop a user that is accessing UI support from SAP HANA studio or SAP HANA
Cockpit, we can easily analyze the impact of the action. This is because we can identify all the
objects owned by the user to be deleted.

Figure 47: Dropping DB Accounts Safely: UI Support in SAP HANA Cockpit
Note:
Dropping users using SQL commands is risky as the objects to be dropped are not
displayed.
You can also analyze the ownership of the objects in your SAP HANA system by using the
system view named “OWNERSHIP”, “SCHEMAS,” or “ROLES” depending on the type of
object you would like to analyze.
Figure 48: Object Ownership Finding Ownership Information

Lesson: Describing object ownership rules
Similar to dropping a user, revoking a privilege from a user can also provoke a “recursive”
revoking situation in cases where the privilege was extended further to other users or roles.
To understand this, you should know that the following options for granting privileges exist:
Granting a privilege to a user or role

This option allows user A to grant a privilege to user B. User B is not allowed to further
extend this privilege to others.
Granting a privilege to a user or role with GRANT/ADMIN option
This option allows user A to grant a privilege to user B. User B is allowed to extend this
privilege to others. For example, user B can extend the same privilege to user C.
Note:
To grant a privilege, the user granting the privilege should be the “owner” of the
privilege (owner of the object related to the privilege) or should have the privilege
assigned to them with the GRANT/ADMIN option.
In the example shown in the figure, Recursive Revoking of Privileges: Take Care when
Dropping Users or Revoking Privileges, user A granted a privilege to user B with the GRANT/
ADMIN option. Afterwards, user B granted the same privilege to user C.
Figure 49: Recursive Revoking of Privileges: Take Care when Dropping Users or Revoking Privileges
If user A revokes the privilege from user B, the privilege is also revoked indirectly from user C
as user B no longer has the privilege. This also happens if user A is dropped from the
database.
In the case of roles, these are owned by the database user who creates them. To create a role,
a database user needs to be granted all the privileges of the role. If any of these privileges are
revoked from the creating user, they are automatically revoked from the role. Similarly, if the
creating user is dropped, all roles that they created are also dropped.
LESSON SUMMARY


Unit 4
Lesson 2
Introducing Authorizations in the SAP HANA
Database
LESSON OBJECTIVES
Describing the Basic Authorization Entities

Before we can start building our authorization and security concept in SAP HANA, it is
important to understand the basic authorization entities and the relationships between them.
The basic authorization entities are defined as follows:
User
Identifies the person accessing the system.
Object
Any database object in the system.
Privilege
Privileges are used to impose restrictions on operations carried out on an object. They
can be granted to a user or to a role.
Role
Roles are a collection of privileges. They can be granted to a user or to another role
(nesting).
Figure 50: Basic Authorization Entities
A database object is owned by a user. Depending on the type of object, there is a set of
privileges associated with the object in order to control which operations can be carried out
on it.

Privileges can be assigned to users directly or indirectly using roles. Privileges are required to
model access control. Roles can be used to structure the access control schemes and model
reusable business roles.
It is recommended that you manage authorization for users accessing roles. Roles can be
nested so that role hierarchies can be implemented. This makes them flexible by allowing
granular authorization management for individual users.
Figure 51: Relationships Between Entities
All the privileges granted directly or indirectly to a user are combined. This means whenever a
user tries to access an object, the system performs an authorization check using the user, the
user's roles, and directly allocated privileges.
It is not possible to explicitly deny privileges. This means that the system does not need to
check all the user's roles. As soon as all requested privileges have been found, the system
aborts the check and grants access.
Several predefined roles exist in the database. Some of the roles are templates that need to
be customized and others can be used as they are.
User management is configured using the SAP HANA Cockpit.
System User Tasks

The steps for managing what users are authorized to do in the system are as follows:
1. Define and create roles.
2. Assign privileges to roles.
3. Create users.
4. Grant roles to the users.

Lesson: Introducing Authorizations in the SAP HANA Database
Figure 52: Authorization Design Process
Describing Privileges
When a user accesses the SAP HANA database using a client interface (for example, ODBC,
JDBC, or HTTP), their ability to perform database operations on database objects is
determined by the privileges that they have been granted.
All the privileges granted to a user, either directly or indirectly through roles, are combined.
This means that whenever a user tries to access an object, the system performs an
authorization check on the user, the user's roles, and the user’s directly granted privileges. It
is not possible to explicitly deny privileges. This means that the system does not need to
check all the user's privileges. As soon as all requested privileges have been found, the
system skips further checks and grants access.
Figure 53: Privilege Types
The following list outlines the various privilege types:
System Privileges
System privileges control general system activities. They are mainly used for
administrative purposes, such as, creating schemas, creating and changing users and
roles, monitoring and tracing. System privileges are also used to authorize basic
repository operations.
Object Privileges
Object privileges are used to allow access to and modification of database objects, such
as, tables and views. Depending on the object type, different actions can be authorized
(for example, SELECT, CREATE ANY, ALTER, and DROP).

Schema privileges are object privileges that are used to allow access to and modification
of schemas and the objects that they contain.
Object privileges granted to users in a particular database, authorize access to and
modification of database objects in that database only.
Analytic Privileges
Analytic privileges are used to allow read access to data in SAP HANA information
models (that is, analytic views, attribute views, and calculation views) depending on
certain values or combinations of values. Analytic privileges are evaluated during query
processing.
Package Privileges (deprecated)
Package privileges are used to allow access to and the ability to work in packages in the
classic repository of the SAP HANA database.
Packages contain design time versions of various objects, such as, analytic views,
attribute views, calculation views, and analytic privileges.
Package privileges granted to users in a particular database, authorize access to and the
ability to work in packages in the repository of that database only.
With SAP HANA extended application services, advanced model (XSA), source code and
Web content are not versioned and stored in the SAP HANA database. Therefore,
package privileges are not used in this context.
Application Privileges (deprecated)
Developers of SAP HANA extended application services, classic model (XSC)
applications can create privileges to authorize user and client access to their application.
They apply in addition to other privileges, for example, object privileges on tables.
Application privileges can be granted directly to users or roles in runtime in the SAP
HANA studio. However, it is recommended to grant application privileges to roles created
in the repository in design time.
With SAP HANA XSA, application privileges are not used. Application-level authorization
is implemented using OAuth and authorization scopes and attributes.
Privileges on Users
An additional privilege type, privileges on users, can be granted to users. Privileges for
users are SQL privileges that users can grant to their user. ATTACH DEBUGGER is the
only privilege that can be granted to a user.
For example, User A can grant User B the privilege ATTACH DEBUGGER to allow User B
debug SQLScript code in User A's session. User A is the only user who can grant this
privilege. User B also needs the object privilege DEBUG on the relevant SQLScript
procedure.
SQL Privileges
In the SAP HANA database, a number of privileges are available to control the authorization of
SQL commands. Following the principle of least privilege, users should only be given the
smallest set of privileges required for their role.
For this purpose two groups of SQL privileges are available:
System privileges

These are system-wide privileges that control some general system activities, mainly for
administrative purposes, such as, creating schema and creating and changing users and
roles.
Object privileges
These privileges are bound to an object, for example, to a database table, and to enable
object-specific control activities, such as, SELECT, UPDATE, or DELETE.
Figure 54: System and Object Privileges
System privileges
System privileges control general system activities. They are mainly used for administrative
purposes, such as, creating schemas, creating and changing users and roles, performing data
backups, managing licenses, and so on.
System privileges are also used to authorize basic repository operations.

Figure 55: System Privileges
System privileges granted to users in a particular database authorize operations in that

database only. The only exception is the system privileges DATABASE ADMIN, DATABASE
STOP, DATABASE START, and DATABASE AUDIT ADMIN. These system privileges can only
be granted to users of the system database. They authorize the execution of operations on
individual tenant databases. For example, a user with DATABASE ADMIN can create and drop
tenant databases, change the database-specific properties in configuration (*.ini) files, and
perform database-specific or full-system data backups.
Note:
System privileges should always be assigned with caution.
Object Privileges
Object privileges are SQL privileges that are used to allow access to and modification of
database objects.
For each SQL statement type (for example, SELECT, UPDATE, or CALL), a corresponding
object privilege exists. If a user wants to execute a particular statement on a simple database
object (for example, a table), he or she must have the corresponding object privilege for either
the actual object itself, or the schema in which the object is located. This is because the
schema is an object type that contains other objects. A user who has object privileges for a
schema automatically has the same privileges for all objects currently in the schema and any
objects created in the system in the future.
Object privileges are not only granted for database catalog objects, such as, tables, views, and
procedures; Object privileges can also be granted for non-catalog objects such as
development objects in the repository of the SAP HANA database.
Initially, the owner of an object and the owner of the schema in which the object is located are
the only users who can access the object and grant object privileges to other users.
An object can therefore be accessed only by the following users:
● The owner of the object
● The owner of the schema in which the object is located

● Users to whom the owner of the object has granted privileges

● Users to whom the owner of the parent schema has granted privileges
Caution:
The database owner concept stipulates that when a database user is deleted, all
objects created by that user and privileges granted to others by that user are
also deleted. If the owner of a schema is deleted, all objects in the schema are
also deleted even if they are owned by a different user. All privileges on these
objects are also deleted.
Note:
The owner of a table can change its ownership with the ALTER TABLE SQL
statement. In this case, the new owner becomes the grantor of all privileges on the
table granted by the original owner. The original owner is also automatically
granted all privileges for the table with the new owner as grantor. This ensures
that the original owner can continue to work with the table as before.
The following list outlines additional information on object privilege activities:

● CREATE ANY
This privilege allows the creation of all kinds of objects, in particular, tables, views,
sequences, synonyms, SQL script functions, or database procedures in a schema. This
privilege can only be granted on a schema.
● ALL PRIVILEGES
This privilege is a collection of all Data Definition Language (DDL) and Data Manipulation
Language (DML) privileges that the grantor currently possesses and is allowed to grant
further. The privilege it grants is specific to the particular object being acted upon. ALL
PRIVILEGES is not applicable to a schema, but only to a table, view, or table type.
● DROP and ALTER
These are DDL privileges and authorize the DROP and ALTER SQL commands. While the
DROP privilege is valid for all kinds of objects, the ALTER privilege is not valid for
sequences and synonyms as their definitions cannot be changed after creation.
● SELECT, INSERT, UPDATE, and DELETE
These are DML privileges and authorize respective SQL commands. While SELECT is valid
for all kinds of objects (except for functions and procedures), INSERT, UPDATE, and
DELETE are only valid for schemas, tables, table types, and updatable views.
● INDEX
This special DDL privilege authorizes the creation, alteration, or revocation of indexes for
an object using the CREATE INDEX, ALTER INDEX, and DROP INDEX commands. This
privilege can only be applied to a schema, table, and table type.
● EXECUTE
This special DML privilege authorizes the execution of an SQL script function or a database
procedure using the CALLS or CALL command, respectively.

Analytic Privileges
Analytic privileges are used to allow read access to data in SAP HANA information models
(that is, analytic views, attribute views, and calculation views) depending on certain values or
combinations of values. Analytic privileges are evaluated during query processing.
Using Analytic Privileges

Standard object privileges (for example, SELECT, ALTER, and DROP) implement coarse-
grained authorization at object level only. Users either have access to an object (such as, a
table, view, or procedure), or they don't. While this is often sufficient, there are cases when
access to data in an object depends on certain values or combinations of values. Analytic
privileges are used in the SAP HANA database to provide detailed control, at row level, for the
data that individual users can see within the same view.
Figure 56: SAP HANA Authorization Runtime Access Control
Analytic Privileges are used in the SAP HANA database to provide fine-grained control of the
data that particular users can see for analytic use. They provide the ability for row-level
authorization, based on the values in one or more columns.
All Calculation Views, which have been designed in the modeler and have been activated, are
supported by the Analytic Privilege mechanism by default.
If you are already familiar with the authorization model of SAP NetWeaver Business
Warehouse (SAP NetWeaver BW), you will see many similarities between the two models.
The overall idea behind Analytic Privileges is the reuse of Analytic Views by different users.
However, different users may not be allowed to see the same data. For example, different
regional sales managers, who are only allowed to see sales data for their regions, could reuse
the same Analytic View. They would use the Analytic Privilege to see only data for their region,
and their queries on the same view would return to the corresponding data. This is a major
difference to the SAP NetWeaver BW model. While the concept itself is very similar, SAP
NetWeaver BW would forward an error message if you executed a query that returns values
that you are not authorized to see. With the SAP HANA database, the query would be
executed and, corresponding to your authorization, only values that you are entitled to see
would be returned.
An Analytic Privilege consists of several restrictions. Three of these restrictions are always
present and have the following special meanings:
● One restriction (cube restriction) determines the Calculation Views for which the privilege
is used. This may involve a single view, a list of views or, by means of a wildcard, all
applicable views.

● One restriction (activity restriction) determines the effected activity (for example, READ).
This means that the activity READ is restricted and not available for use.
● One restriction (validity restriction) determines the times at which the privilege is valid.
In addition to these three restrictions, many additional dimension restrictions are used. These
are applied to the actual attributes of a view. Each dimension restriction is relevant for one
dimension attribute, which can contain multiple value filters. Each value filter is a tuple of an
operator and its operands, used to represent the logical filter condition. For example, a value
filter (EQUAL 2006) can be defined for a dimension attribute YEAR in a dimension restriction
to filter accessible data using the condition YEAR=2006 for potential users.
Only dimension attributes, and no measures or key figures, can be employed in dimension
restrictions.
In general, the user has access to an individual Calculation View if the following prerequisites
are met:
● The user was granted the SELECT privilege on the view or the containing schema.
● The user was granted an Analytic Privilege that is applicable to the view. An Analytic
Privilege is applicable to a view if it contains the view in the Cube restriction and contains
at least one filter on one attribute of this view.
● No SELECT privilege on the underlying base tables or views of this view are required.
Figure 57: Analytic Privileges
Before you implement row-level authorization using analytic privileges, you need to decide
which type of analytic privilege is suitable for your scenario. In general, SQL-based analytic
privileges allow you to more easily formulate complex filter conditions using sub-queries that
might be cumbersome to model using XML-based analytic privileges.
LESSON SUMMARY


Unit 4
Lesson 3
Introducing database roles management
LESSON OBJECTIVES
Describing Database Roles

Overview of Roles
A database role is a collection of privileges that can be granted to either a user or to another
role at runtime.
A role typically contains the privileges required for a particular function or task, such as, the
following:
● Business end users reading reports using client tools
● Modelers creating models and reports in the modeler of the SAP Web IDE for SAP HANA
● Database administrators operating and maintaining the database and the users
Privileges can be granted directly to users of the SAP HANA database. However, roles are the
standard mechanism of granting privileges as they allow you to implement complex, reusable
authorization concepts that can be modeled on business roles
Roles in the SAP HANA database can exist as runtime objects only (catalog roles), or as
design-time objects that become catalog objects on deployment (database artifact with file
suffix .hdbrole).
In an SAP HANA extended applications services, classic model (XSC) environment, database
roles are created in the built-in repository of the SAP HANA database using either the SAP
HANA Web Workbench or the SAP HANA studio. These are also referred to as repository
roles. In an SAP HANA extended applications services advanced model (XSA) environment,
design-time roles are created using the SAP Web IDE and deployed using SAP HANA
deployment infrastructure (SAP HANA DI, or HDI).
Note:
Due to the container-based model of HDI where each container corresponds to a
database schema, HDI roles, once deployed, are schema specific.
SAP HANA XSA has the additional concept of application roles and role collections. These are
independent of database roles in SAP HANA itself. In the XSA context, SAP HANA database
roles are used only to control access to database objects (for example, tables, views, and
procedures) for XSA applications. For more information about the authorization concept of
XS advanced, see the SAP HANA Security Guide.

Figure 58: Role Structure
A role can contain:

● Any number of the following privileges.
● - System privileges for general system authorization, in particular administration
activities (for example, AUDIT ADMIN, BACKUP ADMIN, and CATALOG READ)
- Object privileges (for example, SELECT, INSERT, and UPDATE) on database objects
(for example, schemas, tables, views, procedures, and sequences)
- Analytic privileges on SAP HANA information models
- Package privileges on repository packages (for example, REPO.READ,
REPO.EDIT_NATIVE_OBJECTS, and REPO.ACTIVATE_NATIVE_OBJECTS)
- Application privileges for enabling access to SAP HANA-based applications developed
in an SAP HANA XSC environment
● Other roles: A role can also contain other roles
Note:
There are no HDI or XSA equivalents in the SAP HANA authorization concept for
package privileges on repository packages and applications privileges on SAP
HANA XSC applications. For more information about the authorization concept of
XSA, see the SAP HANA Security Guide.
For the best performance of role operations (in particular, granting and revoking), keep the
following basic rules in mind:
● Create roles with the smallest possible set of privileges for the smallest possible group of
users who can share a role (principle of least privilege).
● Avoid granting object privileges at the schema level to a role if only a few objects in the
schema are relevant for intended users.

Lesson: Introducing database roles management
● Avoid creating and maintaining all roles as a single user. Use several role administrator
users instead.
Types of Roles
Roles in the SAP HANA database can exist as runtime objects only (catalog roles), or as
design-time objects (repository roles) that become catalog objects on deployment (database
artifact with the file suffix .hdbrole).
Before the arrival of SAP HANA XSA, there were two types of roles in HANA: catalog roles,
which are created directly in the catalog, and repository roles, which are created using the
SAP HANA repository.
With the introduction of SAP HANA XSA, new types of roles were also introduced, known as
HDI-based roles. Like repository roles, HDI-based roles provide role versioning and can be
transported between systems.
Types of Roles
● Database (Catalog) Roles

● Design-Time HDI Roles
● Design-Time Repository Roles (deprecated)
In an SAP HANA XSC environment, database roles are created in the built-in repository of the
SAP HANA database using either the SAP HANA Web IDE or the SAP HANA cockpit. These
are also referred to as repository roles. In an SAP HANA XSA environment, design-time roles
are created using the SAP Web IDE and deployed using SAP HANA Deployment Infrastructure
(SAP HANA DI, or HDI).
SAP HANA XSA has the additional concept of application roles and role collections. These are
independent of database roles in SAP HANA itself. In the XSA context, SAP HANA database
roles are used only to control access to database objects (for example, tables, views, and
procedures) for XSA applications. For more information about the authorization concept of
XS advanced, see the SAP HANA Security Guide.
It is possible to create roles as pure runtime objects that follow classic SQL principles or as
design-time objects in either an SAP HANA XSA or XSC environment.
Characterising Catalog Roles and Design Time Roles

It is possible to create roles as pure runtime objects that follow classic SQL principles or as
design-time objects.
In SAP HANA XSC, database roles are created in the built-in repository of the SAP HANA
database using either the SAP HANA Web Workbench or the SAP HANA studio. In SAP HANA
XSA, design-time roles are created using the SAP Web IDE and deployed using SAP HANA
deployment infrastructure (SAP HANA DI, or HDI).
Note:
2.0 SPS 02. For more information, see SAP Note 2465027.
Catalog roles are useful in scenarios where user and role provisioning is carried out solely
using a higher-level application that connects to SAP HANA through a technical user, such as,
SAP Identity Management.

The following table summarizes the differences between catalog roles and design-time roles:
Figure 59: Characteristics of Role Types
In general, it is recommended that you model roles as design-time objects for the following
reasons:
● Unlike roles created at runtime, roles created as design-time objects can be transported
between systems. This is important for application development as it means that
developers can model roles as part of their application's security concept and then ship
these roles or role templates with the application. Being able to transport roles is also
advantageous for modelers implementing complex access control on analytic content.
They can model roles in a test system and then transport them into a production system.
This avoids unnecessary duplication of effort.
● Roles created as design-time objects are not directly associated with a database user.
They are created by technical users and granted through the execution of stored
procedures. Any user with access to these procedures can grant and revoke a role. Roles
created at runtime are granted directly by the database user and can be revoked only by
the granting user or a user with the ROLE ADMIN system privilege. Additionally, if the
database user is deleted, all roles that he or she granted are revoked. As database users
correspond to real people, this could impact the implementation of your authorization
concept, for example, if an employee leaves the organization or is on vacation.
LESSON SUMMARY

Unit 4
Lesson 4
Creating Catalog Roles
LESSON OBJECTIVES
Creating Catalog (Runtime) Roles

A catalog role is also called runtime role; the two names are interchangeable and there is no
difference between them.
You can create catalog roles in the SAP HANA system. A role administrator creates the role in
the runtime of the SAP HANA system. The database user grants catalog roles directly, and
they can only be revoked by the same user.
Figure 60: Catalog Role
Managing catalog roles has several challenges, especially with regard to transportation and
revocation of privileges and roles.

Figure 61: Properties of Catalog Roles
Catalog roles can be created on Role Management page of the SAP HANA Cockpit or using an
SQL command.
Figure 62: Creating Catalog Roles
To create a catalog role, the ROLE ADMIN system privilege is needed. This system privileges
also allows granting of any catalog role.
Prerequisites for Granting Privileges

System privilege

Lesson: Creating Catalog Roles
To grant a system privilege, the granting user requires the system privilege being granted
and to be authorized to grant it to other users and roles.
Object privilege
To grant an object privilege on an object that exists only in runtime, the granting user
needs the object privilege being granted and to be authorized to grant it to other users
and roles.
Role
To grant a role created at runtime, the granting user requires the role being granted and
to be authorized to grant it to other users and roles, or, ROLE ADMIN system privilege.
Figure 63: Difficulties with Catalog Role Creation and Modification
The figure, Difficulties with Catalog Role Creation and Modification, outlines the limitations of
catalog roles, and the main reasons to use application-deployed roles.
The limitations are related to the object ownership concept, which is part of the basic
database functionalities.
There are disadvantages to take into consideration when working with catalog roles. If a user
grants a privilege using the GRANT statement, the privilege is automatically revoked when the
grantor is dropped or loses the granted privileges. Only the grantor can revoke the privilege.
With the stored procedures approach, any user with the EXECUTE privilege on the relevant
revoke procedure can revoke a granted privilege, regardless of the grantor. If the grantor is
dropped, none of the privileges that they granted are revoked.

Figure 64: Lesser-Known Properties of Catalog Roles: Revoking of Roles
Granting Roles to Users

Granting Catalog Roles
You can grant roles to users using the SAP HANA Cockpit, and using the GRANT statement on
the SQL console. As a prerequisite to grant a role to a user, your user should also have the
role with GRANT OPTION, or the role should be created by you.
Figure 65: Grant Catalog Roles to a User
Note:
The system privilege ROLE ADMIN supersedes the GRANT OPTION.
The following list shows some common errors that occur during a save:
● Missing privilege for editing role

Lesson: Creating Catalog Roles
● Missing grant option (for example, system privilege ROLE ADMIN missing), or, without
ROLE ADMIN, GRANT OPTION for the missing role
A role can also be revoked from users in the User Editor of SAP HANA Cockpit, or using the
REVOKE statement.
With regard to the cascaded dropping of privileges, if the user has granted the role to other
users, revoking the role (and the grant option) also revokes the role from the user who has
been granted access.
Figure 66: Revoke Catalog Roles from User
Note:
Only the grantor of a catalog role is allowed to revoke the role from a user.
LESSON SUMMARY


Unit 4
Lesson 5
Creating HDI roles
LESSON OBJECTIVES
schema
HDI Container Isolation

Development Scenarios in SAP HANA XSA
With SAP HANA extended application services, advanced model (XSA), the HANA
Deployment Infrastructure (HDI) was also introduced. HDI is a service layer of the SAP HANA
database that simplifies the deployment of HANA database artifacts.
XSA provides a comprehensive platform for the development and execution of native data-
intensive applications that run efficiently in SAP HANA. It succeeds SAP HANA extended
application services, classic model (XSC), as the default application programming model for
SAP HANA. This changes the way in which database objects, including roles, are developed.
A HDI container can be seen as a database schema and there can be multiple HDI containers
within the SAP HANA database. All database objects deployed within the container are owned
by container-specific technical object owners.
Figure 67: HDI Container
Design-time objects are created within a project stored in the GIT repository. When the
developer deploys the project, a runtime version of the objects is created in a HDI container in
the SAP HANA database.

Figure 68: Developer Scenarios XS Advanced
With XSA, a new controller model has been introduced which is composed of a hierarchy of
organizations and spaces. This new model allows us to separate administration privileges per
organization and space, and to isolate resources and privileges between applications that are
in different spaces.
HDI Container Model

All SAP HANA database artifacts, such as, roles or tables, that are created through XSA are
deployed in the SAP HANA Database within a HDI container. A HDI container is essentially a
database schema. Each container has its own container object owner (also known as #OO
user), some APIs, and a schema for storage.
Figure 69: HDI Container Model
The HDI containers provide security isolation as it is based on a “zero” privileges principle by
default. All objects within a container are owned by the #OO user. This user has the following
characteristics:
● The object owner is a restricted database user.
● The object owner has CREATE ANY privileges on the schema.

Lesson: Creating HDI roles
● However, the object owner has no external privileges by default.
At database level, the container has a schema for storage identified by the suffix #DI.
Figure 70: HDI Container Isolation
In the example in the figure, HDI Container Isolation, view X has no direct reference to table
ERP.Y.
The HDI container isolation also affects the creation of database roles through XSA. When we
create a database role, using XSA, the database role will be deployed within a HDI container
and it will be owned by the database object owner. Therefore, to be able to deploy the roles,
the role can only contain privileges that are assigned to the #OO user with GRANT / ADMIN
option. Otherwise, the deployment will fail due to a “Missing Authorization Error”.
Creating HDI Roles for System Privileges

Role development in XSA
For the development of roles, a real application is not created; only database artifacts (roles)
are utilized. For this, developers will use SAP Web IDE to work on a project within a space in
XSA where they will create the design-time objects. In the space, only two types of services
are needed to create roles:
● HDI Container
● User Provided Service (Optional)

Figure 71: Design-Time HDI Roles
Note:
The initial step is to setup and prepare XSA + SAP Web IDE application. Once the
setup is ready, we need to setup our organization and spaces in a way that suits
the needs of our organization.
How to create spaces, setup users, and call the SAP Web IDE can be found in
chapter Post-Installation Administration Tasks in the SAP Web IDE for SAP HANA
Installation and Upgrade Guide.
Our recommendation is to setup at least a dedicated space for role developing.
You can find more details in the Best practices and recommendations section in
the Best practices and recommendations for developing roles in SAP HANA
document.
Figure 72: Custom Roles for Database Administration

Let's look at a scenario where you want to create your own custom roles for database
administration so that every user can have proper system privileges. You want the roles to be
transportable, so they cannot be catalog roles.
Since roles are database objects, you need to create a HDI Container and store the roles in it.
To create the HDI Container, you access the WebIDE and create a multi-target application
(MTA) containing a SAP HANA Database module.
In the module, you create the design time version of the Roles. When you build the module,
the HDI container is created with the runtime versions of the roles that can be assigned to
users by an administrator user with ROLE ADMIN system privilege.
Figure 73: Additional Privileges for Object Owner
Before you can build the application, the Object Owner needs to be provided with all the
additional authorizations it will use in the roles.
GRANT to #OO user directly

This option consists of granting the external privilege or role directly to the #OO user. After
this, we will be able to deploy the database role within the HDI container. This approach is
similar to the one used with XSC when we needed to grant to the _SYS_REPO user the
privilege with GRANT / ADMIN option to include it in a design-time role.
When using this option, the following challenges exist:
● The #OO is automatically created during the "Build" process when the HDI container is
created. This is a problem when transporting the roles for the first time when we build and
deploy the project, as #OO will be created with minimum privileges and we will get a
"Missing authorizations" error.
● In a development scenario, we can potentially have more than one container for role
building (one per developer) so we will need to manually grant the privilege or role to each
#OO user
GRANT to global role _SYS_DI_OO_DEFAULTS

This option consists of granting the external privilege to the _SYS_DI_OO_DEFAULTS role
instead of granting it directly to the #OO user. The _SYS_DI_OO_DEFAULTS role contains the
set of default privileges that are granted to all HDI container object owner users.
By using this option, we can prepare the required external privileges for our database roles by
granting them in advance to the _SYS_DI_OO_DEFAULTS role. This will solve the issue when

we are deploying the project for the first time or when transporting the roles, as the role will
be granted to the #OO when it is created and the deployment will succeed. Also, there won´t
be any additional work in scenarios with multiples containers as the role will be assigned to all
the #OO users.
However, as the _SYS_DI_OO_DEFAULTS role is assigned to all #OO users, this will break (at
HANA level) the separation created by different spaces at XSA level.
Role development process

Role development is performed by the developers in the Web IDE. A developer will create a
new project in the Web IDE space created for the roles. The developer creates a HDB module
which automatically deploys to a HDI container on the HANA database.
The services required for role development must be known to the project in the mta.yaml file.
The developer can now create:
● Files for granting privileges via the user provided service - .hdbgrants
● Synonyms for object privileges - .hdbsynonyms
● Role definitions - .hdbrole
● Role configuration files - .hdbroleconfig
For further details on how to create the different development objects needed for role
developing, we can take a look at the SAP HANA Developer Guide for SAP HANA XS Advanced
Model.
Creating Application-deployed HDI Roles
Figure 74: Design Time Database Roles and the Transport
HDI roles are created using the SAP Web IDE. You create them as design time development
artifacts (text files with .hdbrole extension) within a MTA development project.
When the project is built, a small software application is created in XSA, together with a HDI
container in the SAP HANA database. In the HDI container, the runtime database roles are
created.

Any change and rebuild of the existing design-time roles in the project will cause an automatic
regeneration of the runtime role, in line with the new design.
When you transport the role to a new system, the design time role is transferred and then
rebuilt. In this way, the runtime version is also aligned to the version in the original system
without the need to be explicitly transferred.
The MTA descriptor contains the metadata of all entities comprising an application, or, the
metadata used by it during deployment or runtime, and the dependencies between them.
The MTA descriptor (the mta.yaml file located in the root project folder) is automatically
generated when an application project is created from scratch, and it is updated when the
project properties change or when a module is added or removed. However, not all the
necessary information can be generated automatically. You need to maintain the descriptor
manually to define resources, properties, and dependencies, as well as fill in missing
information.
Figure 75: Properties of HDI Roles Created Using Design Time Artifacts

Figure 76: The Design Time Role
The design time role is a text file with a .hdbrole extension. The file has a JSON type structure
using curly and square brackets to delimit the content. The file content describes the role
name and the list of privileges to be assigned.
Figure 77: The Structured Privilege
The structured privilege allows you to define authorizations at line and column level within a
specific database table. The design time structured privilege is a text file with
extension .hdbstructuredprivilege.
The definition of the subset of visible data is defined via a (SQL) SELECT statement within the
privilege definition. The privilege is then referenced within the role definition (file .hdbrole).
The role can be assigned to the user.

Creating HDI Roles to Access Objects in a Remote Schema
Figure 78: Create Role with Select Privileges on a Remote Object
Let's take a look at a scenario where you have to create a database role that grants select
privileges to users on a table stored in your SAP HANA database. You want this role to be
transportable from your development system to your test system (you cannot create it as a
catalog role).
The solution steps are as follows:
1. In the XSA cockpit, create a user-defined service that can access the remote schema via a
technical user with select privileges to the remote table.
2. In SAP Web IDE, create a new application.
3. In the application, create a synonym referring to the remote table.
4. In the application, create a view referring to the synonym.
5. In the application, (optionally) create a structured privilege that gives access to specific
columns and lines of the view.
6. In the application, create a role granting access to the structured privilege.
This way, the role is part of an application, and the application can be transported from your
development system to your test system.

Figure 79: Granting the Roles to Users
LESSON SUMMARY
schema

Unit 4
Lesson 6
Comparing Role Types
LESSON OBJECTIVES
Comparing Catalog Roles and Design-Time Roles

Unlike roles created in runtime, roles created as design time objects can be transported
between systems. This is important for application development as it means that developers
can model roles as part of their application's security concept, and then ship these roles or
role templates with the application.
Being able to transport roles is also advantageous for modelers implementing complex
access control on analytic content. They can model roles in a test system, and then transport
them to a production system. This avoids unnecessary duplication of effort.
Roles created as design time objects are not directly associated with a database user. They
are created by a technical user (the object owner for HDI roles) and granted through the
execution of stored procedures. Any user with access to these procedures can grant and
revoke a role.
Roles created in runtime are granted directly by the database user, and can only be revoked
by the same user. Additionally, if the database user is deleted, all roles that they have granted
are revoked. As database users correspond to real people, this could impact the
implementation of your authorization concept (for example, if an employee leaves the
organization or is on vacation).
Figure 80: Manage Roles: HDI (application-deployed) Versus Runtime-only

LESSON SUMMARY

Unit 4
Learning Assessment
1. The owner of an object is the user who creates the object.

X True
X False
2. Which of the following privilege types exist in SAP HANA?

X A Object
X B Role
X C System
X D Group
X E Package
X F Analytic
3. A role cannot be granted to another role.

X True
X False
4. Catalog roles are owned by the database user who creates them.
X True
X False

Unit 4: Learning Assessment
5. In a MTA, you create a role containing a system privilege. Which of the following
alternative actions will allow you to build the application without errors?
X A Grant the system privilege to the ##OO user of the generated HDI container.
X B Include the system privilege in a n .hdbgrants file within the application.
X C Grant the system privilege to the _SYS_DI_OO_DEFAULTS role.
6. In a MTA, you want to create a HDI role that grants select privileges to a database table
located in a schema in a different SAP HANA Database. What do you use, in XSA, to
access the remote database?
X A A SAP HANA service
X B A user-defined service
X C A Connectivity service
X D A Destination
X E A Route

Unit 4
1. The owner of an object is the user who creates the object.

X True
X False
This is correct. The owner of an object is the user who creates the object.
2. Which of the following privilege types exist in SAP HANA?

X A Object
X B Role
X C System
X D Group
X E Package
X F Analytic
This is correct. Object, System, Package, and Analytic are all privilege types in SAP HANA.
3. A role cannot be granted to another role.

X True
X False
This is correct. A role can be granted to another role.

Unit 4: Learning Assessment - Answers
4. Catalog roles are owned by the database user who creates them.
X True
X False
Correct. Catalog roles are owned by the database user who creates them.
5. In a MTA, you create a role containing a system privilege. Which of the following
alternative actions will allow you to build the application without errors?
X A Grant the system privilege to the ##OO user of the generated HDI container.
X B Include the system privilege in a n .hdbgrants file within the application.
X C Grant the system privilege to the _SYS_DI_OO_DEFAULTS role.
This is correct! When you create a role containing a system privilege, you need to grant
the same privilege to the #OO user of the generated HDI container. Alternatively, you can
grant it to the _SYS_DI_OO_DEFAULTS role.
6. In a MTA, you want to create a HDI role that grants select privileges to a database table
located in a schema in a different SAP HANA Database. What do you use, in XSA, to
access the remote database?
X A A SAP HANA service
X B A user-defined service
X C A Connectivity service
X D A Destination
X E A Route
This is correct. You use a user defined-service.

UNIT 5 Setting up personal database
user accounts
Lesson 1
Set up personalized database administrator users 117
UNIT OBJECTIVES
● Knowing the SYSTEM database user

Unit 5: Setting up personal database user accounts

Unit 5
Lesson 1
Set up personalized database administrator
users
LESSON OBJECTIVES
The SYSTEM database user

Management of the SYSTEM User
The SYSTEM database user is the initial user that is created during the installation of the SAP
HANA database system or creation of individual tenant databases.
SYSTEM is the database superuser. It has irrevocable system privileges, such as, the ability to
create other database users, access system tables, and so on, but it does not have
permission to access the contents of the tables of an SAP system, e.g. SAP ERP or SAP S/
4HANA, as well as the schemes of SAP HANA Deployment Infrastructure (HDI) containers. In
addition, to ensure that the administration tool (SAP HANA cockpit) can be used immediately
after database creation, SYSTEM is automatically granted several roles the first time the
cockpit is opened with this user.
Note:
However, the SYSTEM does not automatically have access to objects created in
the SAP HANA repository.
In a system with multitenant database containers, the SYSTEM user of the system database
has additional privileges for managing tenant databases, for example, creating and dropping
databases, changing configuration (*.ini) files of databases, and performing database-specific
data backups.
It is important that the SYSTEM user is not scheduled for any background tasks, is not used in
interfaces, and its login data is not used for connections (e.g. in the SAP HANA Cockpit).

Figure 81: The SYSTEM user
If the SYSTEM user's password is lost, you can reset it using the operating system user
(<sid>adm user). Changing the system parameter indexserver.ini - password
policy - password_lock_for_system_user (default value: TRUE), to the FALSE value,
forces the SYSTEM user so that they cannot be locked through false login attempts. This
enables brute force attacks on this user. We recommend the parameter value should remain
set to the TRUE default value.
The SYSTEM user of the system database requires the following additional system privileges
in comparison to the system user of a tenant database:
● DATABASE ADMIN
● DATABASE AUDIT ADMIN
● DATABASE BACKUP ADMIN
● DATABASE BACKUP OPERATOR
● DATABASE RECOVERY OPERATOR
● DATABASE START
● DATABASE STOP
Note:
You can find more about assigning important system privileges to administrator
users in SAP Note: 2950209 - Critical System Privilege in SAP HANA Database.
Creating new database administrator users

Building personalized database administrator users
As mentioned previously, the database user SYSTEM is the most powerful database user, and
is active after database creation.

Lesson: Set up personalized database administrator users
The SYSTEM user is the built-in user designed to bootstrap the database. Bootstrapping
entails creating the initial system setup, which includes a list of objects, user and roles, as well
as the initial system configuration.
Do not use SYSTEM for day-to-day activities in production systems. Instead, use it to create
database users with the minimum privilege required for their duties set (for example, user
administration,and system administration) and then deactivate the SYSTEM.
Note:
In the context of updating a SAP HANA extended application services, advanced
model (XSA) runtime installation, a lesser-privileged database user cannot be
used. The SYSTEM user is required and needs to be temporarily reactivated for
the duration of the update.
Figure 82: Create new administrator user
Separation of administrative duties and responsibilities can be achieved by following steps:
1. Create a user with USER ADMIN privilege.
2. Create personalized administrator accounts.
Depending upon your organization compliance and governance requirements, administrator

accounts with lower level privileges should be set up. Sample users could include:
● User Administrator
● Database Administrator
● Backup Administrator
● …

Figure 83: Assign system privileges to new administrator user
Each user should be granted a corresponding role. Multiple privileges can be combined and
assigned to a role.
Note:
It is not advised to create a copy of the SYSTEM user, as it would be another
powerful user. The next logical step is to define and create roles for those
administrative accounts.
A role and authorization concept should be implemented according to your organizational

needs. A general recommendation is to create design-time roles with an .hdirole as the
extension. Design-time roles should be as granular as possible, and contain the minimum
number of privileges.
Deactivating the SYSTEM database user

Lock the SYSTEM database user
As the most powerful database user, SYSTEM is not intended for use in production systems.
Use it to create lesser privileged users for particular purposes and then deactivate it. To
deactivate the SYSTEM user, you need the USER ADMIN system privilege.

Lesson: Set up personalized database administrator users
Figure 84: Deactivate the SYSTEM database user
In the SAP HANA cockpit, search for the User & Role Management card and click the User
Management link. In the User Management app, scroll down the Users list or leverage the
search field to filter for the desired user.
Choose the Deactivate button and confirm the dialog box.
Alternatively you can execute the following SQL statement:
ALTER USER SYSTEM DEACTIVATE USER NOW;
Note:
The SYSTEM user is not required to update the SAP HANA database system; a
lesser-privileged user can be created for this purpose.
The SYSTEM user is deactivated and can no longer connect to the SAP HANA database.
However, it may appear as though SYSTEM is still active in the system (for example, when a
procedure that was created by SYSTEM with DEFINER MODE is called).
You can verify that the SYSTEM user is deactivated in the USERS system view. For SYSTEM
user, check the values in theUSER_DEACTIVATED, DEACTIVATION_TIME, and
LAST_SUCCESSFUL_CONNECT columns.
You can still use the SYSTEM user as an emergency user even if it has been deactivated. Any
user with the USER ADMIN system privilege can reactivate SYSTEM with the statement
ALTER USER SYSTEM ACTIVATE USER NOW.
Note:
To ensure that an administrator does not do this surreptitiously, it is
recommended that you create an audit policy monitoring ALTER USER
statements. Also change the password of the SYSTEM user after reactivating it.
You can find more about deactivating the SYSTEM user in 2493657 - How do I
deactivate the SYSTEM User?.

Reactivating the SYSTEM database user

Unlock the SYSTEM database user
In rare situations like an emergency or upgrade SAP support package stacks, SAP
enhancement packages and SAP systems use the Software Update Manager (SUM) to install,
migrate, and provision SAP systems using the Software Provisioning Manager (SWPM). The
SYSTEM user is required and needs to be temporarily reactivated for the duration of the
upgrade, installation, migration, or provisioning.
Figure 85: Activate the SYSTEM database user
In the SAP HANA cockpit, search for the User & Role Management card and start the User
Management app. Search and select the SYSTEM user.
Choose the Activate button and confirm the dialog box.
Alternatively you can execute the following SQL statement:
ALTER USER SYSTEM ACTIVATE USER NOW;
LESSON SUMMARY

Unit 5
Learning Assessment
1. The SYSTEM user is required to update the SAP HANA database.

X True
X False
2. Which privilege do you need to deactivate the SYSTEM user?

X A TRUST ADMIN
X B ALTER
X C USER ADMIN
X D UPDATE

Unit 5
1. The SYSTEM user is required to update the SAP HANA database.

X True
X False
Correct. The SYSTEM user is not required to update the SAP HANA database system; a
lesser-privileged user can be created for this purpose.
2. Which privilege do you need to deactivate the SYSTEM user?

X A TRUST ADMIN
X B ALTER
X C USER ADMIN
X D UPDATE
That is correct. To deactivate the SYSTEM user, you need the USER ADMIN system
privilege.

UNIT 6 Managing authentication
Lesson 1
Managing Authentication 127
UNIT OBJECTIVES
● Describe the different authentication mechanisms availablein SAP HANA

Unit 6: Managing authentication

Unit 6
Lesson 1
Managing Authentication
LESSON OBJECTIVES
Describing Authentication Mechanisms

The identity of database users accessing SAP HANA is verified through a process
called authentication. SAP HANA supports several authentication mechanisms, several of
which can be used for the integration of SAP HANA into a single sign-on environment (SSO).
The mechanisms used to authenticate individual users are specified as part of the user
definition.
The following authentication mechanisms are supported in SAP HANA (mechanisms that are
not required can be disabled):
Basic authentication (user name and password)

Users accessing the SAP HANA database authenticate themselves by entering their
database user name and password.
Kerberos, SPNEGO
A Kerberos authentication provider can be used to authenticate users accessing SAP
HANA in the following ways:
● Directly from ODBC and JDBC database clients within a network
● Indirectly from front-end applications, such as, SAP BusinessObjects applications and
other SAP HANA databases using Kerberos delegation
● Via HTTP/HTTPS access by means of SAP HANA extended application services,
advanced (XSA) and classic model (XSC). In this case, Kerberos authentication is
enabled with Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO).
Security assertion markup language (SAML)

An SAML bearer assertion can be used to authenticate users accessing SAP HANA
directly from ODBC/JDBC database clients. SAP HANA can act as a service provider to
authenticate users accessing via HTTP/HTTPS by means of XSC.
Logon and assertion tickets
Users can be authenticated by SAP logon or assertion tickets issued to them when they
log on to an SAP system that is configured to create tickets (for example, the SAP Web
Application Server or Portal).
X.509 client certificates

For HTTP/HTTPS access to SAP HANA by means of XSC and XSA, users can be
authenticated by client certificates signed by a trusted Certification Authority (CA),
which can be stored in the SAP HANA XS trust store.
JSON Web Token (JWT)
A JSON Web Token can be used to authenticate users accessing SAP HANA directly from
ODBC/JDBC database clients or indirectly through XSA.
Lightweight Directory Access Protocol (LDAP)
A password stored in an LDAP directory server can be used to authenticate users
accessing SAP HANA directly from ODBC/JDBC database clients, if authentication using
users' local SAP HANA authentication has been disabled.
Note:
A user who connects to the database using an external authentication
provider must also have a database user known to the database. The
external identity and the database user name are the same. If the LDAP
provider is enabled to create database users in SAP HANA, the required
user is created automatically if it doesn't exist.
Session cookies
Session cookies are not technically an authentication mechanism. However, they
reconnect users who have already been authenticated by Kerberos or SAML and extend
the validity period of logon and assertion tickets.
Figure 86: User Configuration for Authentication and SSO

Lesson: Managing Authentication
Note:
For JDBC and ODBC client connection, user passwords are always transmitted in
encrypted hashed form during the user authentication process, never in plain text.
For HTTP connections, HTTPS must be configured. In SSO environments, we
recommend using encrypted communication channels for all client connections.
A user who connects to the database using an external authentication provider
must also have a database user known to the database. The external identity is
mapped to the identity of an internal database user.
Isolated Single Sign-On for Tenant Databases

Separate database-specific authentication is possible for every certificate-based
authentication mechanism since it is possible to create different certificate collections for
individual purposes directly in every database, and every database can have its own key pair
and public key certificate.
For SAML assertions, X.509 certificates, JSON web tokens, and logon tickets, it is also
possible to use certificate collections (or PSEs) located on the file system. It is still possible to
configure different trust and key stores for every database in the global.ini file. However, bear
the following points in mind:
● If different trust and key stores are not explicitly configured for tenant databases, the
same ones will be used for all external communication channels (including HTTP) for all
databases.
Caution:
If you have configured, in tenant databases or the system database, single sign-
on mechanisms that rely on trust stores located in the file system (such as, SAP
logon and assertion tickets or SAML) and the trust stores are shared, users of
one tenant database may be able to log on to other databases in the system.
● By default, only the system administrator can configure separate trust and key stores for
tenant databases by changing the relevant properties in the global.ini file. This is
because tenant database administrators are prevented from changing any communication
properties. They are in the default configuration change blocklist multidb.ini.
For Kerberos-based authentication, a per-database configuration is not possible; users in all

databases must be mapped to users in the same Key Distribution Center.
Disabling Authentication Mechanisms

By default, all authentication mechanisms are enabled, but it is possible and recommended to
disable those that are not used in your environment. You do this by configuring the parameter
[authentication] → authentication_methods in the global.ini configuration file. The value of
this parameter specifies all enabled methods as a comma-separated list.
The default value is
pbkdf2,password,kerberos,spnego,saml,saplogon,x509xs,jwt,sessioncookie,
ldap.
pbkdf2 refers to password authentication using passwords hashed with PBKDF2 (Password-
Based Key Derivation Function 2), while password refers to password authentication using

passwords hashed with secure hash algorithm SHA-256. Even if a password is listed as a
supported authentication method here, a user will not be able to log on with a SHA-256
hashed password if this hash method has been disabled with the parameter [authentication]
→ password_hash_methods.
Note:
If you are using SAP HANA dynamic tiering, it is not possible to disable logon and
assertion tickets (SAP Logon) as an authentication mechanism.
Changes to the parameter authentication_methods are audited by default if auditing is

enabled.
Configuring Password Policy

Passwords for the basic authentication of database users are subject to certain rules. These
rules are defined in the password policy.
SAP HANA has a default password policy that applies to all users who log on with a user name
and password. You can change the default password policy in line with your organization’s
security requirements. The password policy is defined by parameters in the password
policy section of the indexserver.ini system properties file.
You can view and change the database password policy on the Password Policy and Exclude
List page of the SAP HANA cockpit. You can also query the system view
M_PASSWORD_POLICY to see the current database password policy.
Caution:
Do not change configuration files directly. These changes cannot be audited.
Figure 87: Authentication Information in SAP HANA Cockpit
In the Password Exclude List area of the Authentication app, add the words or partial words
that you want to prohibit in passwords. This is implemented in SAP HANA with the table

_SYS_PASSWORD_BLACKLIST in the schema _SYS_SECURITY. This table is empty when you

create a new instance.
Figure 88: Configuring the password policy and add unwanted words to the blocklist
To view and edit information about authentication, the administrator needs the system
privileges CATALOG_READ and INIFILE ADMIN and must be granted the SELECT, INSERT,
and DELETE object privileges on the _SYS_PASSWORD_BLACKLIST table in the
_SYS_SECURITY schema.
Using other tools to configure password policies

Setting password policy parameters using SQL allows you to:
● Maintain password policy parameters in the system database. Parameters are stored in
the nameserver.ini file; in a tenant database they are stored in the indexserver.ini file.
● Set the minimal password length to the value 10 in the system database:
ALTER SYSTEM ALTER CONFIGURATION ('nameserver.ini', 'SYSTEM') SET
('password policy', 'minimal_password_length') = '10'
● Set the minimal password length to the value 10 in a tenant database:
ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'DATABASE') SET
('password policy', 'minimal_password_length') = '10'
● Set the minimal password length to the value 10 in the system database for a tenant
database:
ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'DATABASE',
'<tenant_database_name>') SET ('password policy',
'minimal_password_length') = '10'
The console tool setParameter.py can be used either when the database is offline or online, if
for any reason it is not possible to make a configuration parameter change by executing an
SQL statement. The tool ensures that if changes are made simultaneously to an *.ini file the
changes are synchronized and applied correctly, this eliminates the need for administrators
to directly edit ini files. You can use the tool as a script to set or unset multiple values at the
same time.

The following example sets the password length to 10. The reconfigure argument is used
(assuming the system is running) so the command will also attempt to reconfigure the
service:
python setParameter.py -set="DATABASE:<database_name>/indexserver.ini/
password policy/minimal_password_length=10" -comment="<your_comment>" -
reconfigure -sapcontrol=1
After submitting the command one of the following codes is returned indicating success or
failure of the execution:
● 0 - Successful execution
● 1 - Could not be executed because of incorrect usage (unexpected parameter values)
● 2 - Other error
If the -sapcontrol=1 switch is set then one of the following is printed in the output:
● SAPCONTROL-OK
● SAPCONTROL-ERROR:<errorMsg>
User Group-Specific Password Policies

The SAP HANA database comes with a default password policy. You can change this default
password policy in line with your organization’s security requirements. If you manage users in
user groups, you can also configure group-specific password policies.
Figure 89: User Group-specific Password Policies
If the users of a user group have different password requirements, you can configure group-
specific values for the individual parameters of the password policy in the definition of the
user groups.
You need the USERGROUP OPERATOR object privilege on the user group. If the user group is
configured for shared administration (administration mode: Group and user administrators),
USER ADMIN system privilege is also sufficient.
To configure a password policy for a specific user group, the following steps must be
performed in the SAP HANA cockpit:

1. On the Database Overview page, with the Security and User Management or All
view selected, choose the User Group Management link.
2. Select the relevant user group.
3. In the Password Policy area, choose Configure or Edit and configure the options in line with
the user group's requirements.
Note:
The initial values for all options are copied from the password policy
configured for the database. If you do not configure a group-specific value for a
particular parameter, the value from database password policy applies.
Choosing Reset Default reapplies all values from the database password
policy.
4. To enable the group password policy, choose Save and Enable.
To determine which password policy a user is currently subject to, query the system view:
M_EFFECTIVE_PASSWORD_POLICY:
SELECT * from "PUBLIC"."M_EFFECTIVE_PASSWORD_POLICY" where USER_NAME =
'<user_name>';
Note:
In the Manage User Groups lesson, the following example creates a user group
called AdminGroup and sets several password policy options for the usergroup:
CREATE USERGROUP AdminGroup SET PARAMETER
'password_layout' = 'A1a!', 'minimal_password_length' =
'12' ENABLE PARAMETER SET 'password policy';
If a group-specific value is not explicitly set for a parameter, the value configured in the
password policy of the database appears as the user group value in
USERGROUP_PARAMETERS.
Integrating Single Sign-On

Kerberos
Kerberos is a network authentication protocol that provides authentication for client-server
applications across an insecure network connection using secret-key cryptography.
For integration into Kerberos-based SSO scenarios, SAP HANA supports Kerberos version 5
based on Active Directory (Microsoft Windows Server) or Kerberos authentication servers.
For HTTP access using XSA and XSC, Kerberos authentication is enabled with Simple and
Protected GSSAPI Negotiation Mechanism (SPNEGO).

Figure 90: Introduction: Using Kerberos for Single Sign-On
ODBC and JDBC database clients support the Kerberos protocol. Access from front-end
applications (for example, SAP BusinessObjects XI applications) can also be implemented
using Kerberos delegation. Support for constrained delegation and protocol transition is
limited to scenarios in which the middle-tier application connects to SAP HANA as the
database layer via JDBC.
Kerberos is supported for HTTP access using XSA and XSC with SPNEGO. It is up to the HTTP
client whether it uses Kerberos directly or SPNEGO.
The indirect authentication option is used in SDA (Smart Data Access) scenarios between
different SAP HANA or Hadoop systems, where the login to the first database can be reused
in another system connected to the first as a remote source.
Figure 91: Kerberos Constrained Delegation
SAP HANA smart data access makes it possible to connect remote data sources, and to
present the data contained in these data sources as if from local SAP HANA tables. This can
be used, for example, in SAP Business Warehouse installations running on SAP HANA to
integrate data from remote data sources.

Connections from SAP HANA system (source) to the remote source system (target) can be
authenticated through Kerberos single sign-on (SSO), in case the remote source is an SAP
HANA or Hadoop system.
Figure 92: Kerberos Configuration: ODBC/JDBC
To allow users to log on to the SAP HANA database from a client using Kerberos
authentication, the following configuration steps are necessary:
1. Install MIT Kerberos client libraries on the host(s) of the SAP HANA system.
2. Configure the SAP HANA system for Kerberos and/or SPNEGO authentication.
3. Map SAP HANA database users to their external identities stored in the Kerberos key
distribution center (KDC).
Note:
In distributed SAP HANA systems that use Kerberos delegation (SSO2DB),
application disruptions resulting from expired authentication are avoided though
the use of session cookies. This mechanism is active by default.
Since the keys stored in the keytab are generated from the service user password, you should
change the service user password periodically. After the password has been changed, the
keytab has to be either created again or extended to contain the new key(s), since a password
change implies an increment of the Key Version Number (KVNO).
Note:
For more information, see SAP Note: 1813724 - HANA SSO using Kerberos and
SPNEGO: Create keytab and validate Kerberos configuration
SAML
SAP HANA supports the Security Assertion Markup Language (SAML) for user authentication
in single sign-on environments. SAML is used for authentication purposes only, and not for
authorization.

Figure 93: Introduction to SAML
SAML provides the mechanism by which the identity of users accessing the SAP HANA
database from client applications is authenticated. This authentication is done by XML-based
assertions that are issued by a trusted identity provider. The internal database user to which
the external identity is mapped is used for authorization checks during the database session.
Figure 94: What is SAML?
With SAML, a user can log on to one system in an environment, and then access other
systems in that environment without needing to log on again (until the Web browser session is
ended).
The Identity Provider (IDP) maintains a directory of users and an authentication mechanism
to authenticate them. The Service Provider is the target application that a user tries to utilize.
The principal must be registered in the IDP.

Figure 95: How it Works for HTTP(S) Access
The figure, How it Works for HTTP(S) Access, depicts the standard scenario for SAML
authentication usage between Web applications.
The IDP can authenticate the user in different ways (for example, using another SSO option
like Kerberos).
To enable logon using SAML bearer assertions, you must configure identity providers and
then map them to the required database users.
Two types of user mapping are supported, as follows:
SAP HANA-based user mappings

An external identity is mapped to a database user explicitly in the SAP HANA in the user
definition for each identity provider.
Identity provider-based user mappings
The identity provider maps its users to SAP HANA database users and provides this
information using the SPProvidedID attribute.
You can configure SAML identity providers and configure user mapping for ODBC/JDBC-
based SAML authentication in the SAP HANA Cockpit.

Figure 96: SAML Configuration in SAP HANA Cockpit
To add a SAML Provider in the SAP HANA cockpit, you must have the following prerequisites:
● The USER ADMIN system privilege.
● A certificate collection created with the SAML purpose in the database, and have imported
the X.509 certificates that will be used to sign the SAML assertions from the IDP. Ensure
that the entire certificate chain of the X.509 certificate is available.
● The configured [authentication] saml_service_provider_name system property, if
necessary.
You can configure an SAP HANA system to act as a service provider for XSA that use single
sign-on (SSO) authentication based on Security Assertion Markup Language (SAML)
certificates.
The XSA Cockpit includes Trust Configuration, which you can use to configure SAML identity
providers at runtime. If you want your XSA applications to use SAML assertions as the logon
authentication method, the following steps must be performed:
● - Create a SAML IDP
- Manage trust configurations
- Map role collections to an SAML IDP
Note:
To use strong cryptographic keys with at least 256 bit in the SAML 2.0
assertion token, install Java Cryptography Extension (JCE) in your SAP JVM
and activate the use of 'unlimited' cryptographic keys.
For more information, see SAP Note 1240081 - Java Cryptography Extension
(JCE) Jurisdiction Policy Files.
While you can configure SAML providers for ODBC/JDBC-based SAML authentication using
the SAP HANA cockpit or SQL, always use the SAP HANA XS Administration Tool to configure

SAML providers that will be used for HTTP access via the XS server. You also use the SAP
HANA XS Administration Tool to configure an SAP HANA system to act as an SAML service
provider.
Figure 97: SAML Configuration for XS Engine applications
The SAP HANA XS Administration Tool is available on the SAP HANA XS Web server at the
following URL: http://<WebServerHost>:80<SAPHANAinstance>/sap/hana/xs/
admin/.
The information required to maintain details of an SAML IDP is specified in an XML document
containing the IDP metadata.
To add the new SAML IDP to the list of known SAML IDPs, choose Create. The new SAML IDP
is displayed in the list of known IDPs on the left-hand side of the SAML CONFIGURATION tool.
X.509 Certificates
For HTTP/HTTPS access to SAP HANA by means of SAP HANA XS, users can be
authenticated by client certificates signed by a trusted Certification Authority (CA), which can
be stored in the SAP HANA XS trust store.
Figure 98: X.509 Certificates Introduction
To implement X.509 client certificates, the user specified in the certificate must already exist
in SAP HANA. There is no support for user mapping.

Figure 99: X.509 Certificates Configuration Overview
Note:
CommonCryptoLib is installed by default as part of SAP HANA server installation
in the usr/sap/<SID>/SYS/global/security/lib directory.
There are multiple trust stores to maintain, which are as follows:

● The SAP HANA trust store (sapsrv.pse)
● The SAP Web Dispatcher trust store (SAPSSL.pse)
● The client authentication trust store (sapcli.pse) for servers connecting to SAP HANA
Figure 100: X.509 Usage
The SAP HANA XS Administration Tool is available on the SAP HANA XS Web server at the
following URL: http://<WebServerHost>:80<SAPHANAinstance>/sap/hana/xs/admin/

The SAP HANA XS Administration Tool is a Web-based tool that enables you to configure and
maintain the basic administration-related elements of the application-development process
and environment.
When you enter the URL for your application in the Web browser, it prompts you to select a
certificate, which enables you to log on without supplying logon credentials manually.
Configure SSO with X.509 Authentication for XS Advanced Applications

Enable SSO with X.509 certificates for user logon to applications in the XS advanced run-time
environment.
Prerequisites:
● You have the role USER_ADMIN on your SAP HANA database.
● You have the role XS_CONTROLLER_ADMIN on your XS advanced runtime.
● You have an SAP HANA administration tool.
● A root certificate of the X.509 user certificates is present.
● The uaa.oidc.enableoidc and uaa.oidc.enablex509 parameters in the xsuaaserver.ini
file are set to true.
1. Add the root certificate of the X.509 user certificates in PEM format to your XS advanced
runtime platform.
2. Create a new user in the SAP HANA database based on the details specified in an existing
X.509 certificate. For example:
CREATE USER MyUserName WITH IDENTITY 'CN=MyUserName, O=SAP-AG, C=DE'
ISSUER 'CN=SSO_CA, O=SAP-AG, C=DE' FOR X509
3. Configure the user in SAP HANA. Use the SAP HANA administration tool of your choice,
select X509 and Configure X.509 user certificates.
4. Test the logon authentication settings for the XS advanced application using a Web
browser.
Entering the URL for your application in the Web browser, it prompts you to select a
certificate, which enables you to log on without supplying logon credentials manually.
SAP Logon and Assertion Tickets

Users can be authenticated in SAP HANA by logon or assertion tickets issued to them when
they log on to an SAP system configured to create tickets (for example, the SAP Web
Application Server or Portal).
If you want to integrate an SAP HANA system into a landscape that uses logon or assertion
tickets for user authentication, you must configure SAP HANA to accept logon/assertion
tickets.

Figure 101: SAP Logon Tickets
The SAP Logon Ticket is an authentication token that can be used for repeated authentication
on the system that created it or for authentication on systems other than the system that
created it, eliminating the requirement to repeatedly enter logon IDs and passwords to get
access to those systems. It is typically transmitted as a non-persistent cookie and contains
details about the user and the system that created it but it does not contain user passwords.
The SAP logon ticket has a lifetime that is configured in the system that creates the ticket.
Figure 102: SAP Assertion Tickets
Logon tickets are used for user-to-system communication, whereas assertion tickets are
used for system-to-system communication. Logon tickets are transmitted as cookies,
whereas assertion tickets are transported as HTTP headers.
The validity of logon tickets is configured, whereas the validity of assertion tickets is hard-
coded (2 minutes).
Logon tickets never identify a recipient, as they target multiple systems. Assertion tickets are
always issued for a single recipient.
SAP HANA validates incoming logon/assertion tickets against certificates signed by a trusted
Certification Authority (CA) and stored in a dedicated trust store. This trust store must
contain all root certificate(s) used to validate logon/assertion tickets.

Figure 103: SAP Logon and Assertion Tickets Prerequisites: Trust Store
Caution:
By default, the same trust store in the file system is shared by all databases.
Different PSEs must be explicitly configured for tenant databases.
The user named in an incoming logon ticket must exist as a database user. The database user
also must be configured for authentication using logon/assertion tickets.
Figure 104: SAP Logon and Assertion Tickets Prerequisites: User Configuration
Single Sign-On Using JSON Web Tokens

JSON Web Token (JWT) is an open standard. SAP HANA supports JSON Web Tokens (JWT)
for user authentication in single sign-on environments.
The identity of users accessing the SAP HANA database from client applications can be
authenticated by tokens issued by a trusted IDP. The internal database user to which the
external identity is mapped is used for authorization checks during the database session.
JWT can be implemented to authenticate users accessing the SAP HANA database from the
following client applications:
● Database clients that access the SQL interface of the SAP HANA database directly

● Clients that connect to SAP HANA through the SAP HANA XS advanced server
Note:
To avoid replay attacks, we recommend that you set up secure communication
between the individual components of the SAP HANA database and client
connections using the Transport Layer Security (TLS) protocol when
implementing JWT authentication.
Figure 105: How JWT-based authentication works
SAP HANA validates tokens according to the Internet Engineering Task Force (IETF)
standard, with the following restrictions and requirements.
The header part of the token claims the hashing algorithm used to generate the signature
(must be RS256):
{
"alg": "RS256",
"typ": "JWT"
}
SAP HANA evaluates the following claims in the payload part of the token:
● "iss" (issuer): Is required to map the token to an identity provider configured in the SAP
HANA database.
● "user_name" (user name): Is required for mapping the database user to an external user
name.
● "nbf" (not before) and "exp" (expiration time): Define the validity period of the token:
{
●
"iss": "http://localhost:8080/uaa/oauth/token",
"user_name": "testuser",
"nbf": 1489571999,
"exp": 1489572899,
}

The configuration for the "user_name" claim is defined in the IDP when it is created in SAP
HANA:
CREATE JWT PROVIDER my_jwt_provider WITH ISSUER 'http://example.com:
8080/uaa/
oauth/token' CLAIM 'testuser' AS EXTERNAL IDENTITY;
Add a JSON Web Token IDP in SAP HANA Cockpit

If you are using JSON Web Tokens (JWT) to authenticate users accessing SAP HANA via the
SQL interface directly (that is, using JDBC and ODBC clients) or clients that connect to SAP
HANA through the SAP HANA XS advanced server, you must add the JWT identity providers
for the required users.
Figure 106: Add a JWT Identity Provider in SAP HANA Cockpit
1. On the Database Overview page, with the Security and User Management or All view
selected, navigate to Security Related Links and choose JWT Identity Providers.
2. Choose the Add Identity Provider button.
3. On the Identity Provider dialog screen:
● Specify a name for the IDP.
● Enter the issuer URL - this is used to map the token to an identity provider. It
corresponds to the name provided in the "iss" claim of the JWT tokens issued by this
JWT provider.
● Enter the JWT identity claim - this is the claim in the JWT token used for mapping the
SAP HANA user to an external user name.
● Choose Add.
The IDP can now be mapped to individual database users. You map the IDP when you create
the database user. Alternatively, if the database user already exists, you can change the
user's authentication details.

LESSON SUMMARY

Unit 6
Learning Assessment
1. Which of the following authentication mechanisms are supported in SAP HANA?

X A Kerberos
X B Enterprise Single Sign-On Engine
X C SAML
X D SAP Logon and assertion tickets
X E Basic authentication (user/password)
2. Are all the authentication mechanisms enabled by default in SAP HANA?

X True
X False

Unit 6
1. Which of the following authentication mechanisms are supported in SAP HANA?

X A Kerberos
X B Enterprise Single Sign-On Engine
X C SAML
X D SAP Logon and assertion tickets
X E Basic authentication (user/password)
This is correct. Kerberos, SAML, SAP logon and assertion tickets, and basic authentication
are all supported in SAP HANA.
2. Are all the authentication mechanisms enabled by default in SAP HANA?

X True
X False
This is correct. All the authentication mechanisms are enabled by default in SAP HANA

UNIT 7 Enabling cross-database
authorization in tenant
databases
Lesson 1
Describing Cross-Database Authorizations in Tenant Databases 151
UNIT OBJECTIVES
● Describe Cross-Database Authorizations in Tenant Databases

Unit 7: Enabling cross-database authorization in tenant databases

Unit 7
Lesson 1
Describing Cross-Database Authorizations in
Tenant Databases
LESSON OBJECTIVES
Describing Cross-Database Authorizations in Tenant Databases

Cross-Tenant Authorization in Tenant Databases
A SAP HANA multitenant database system specifies that every tenant database is self-
contained with its own isolated set of database users and isolated database catalog by
default. This ensures that data in one database cannot be accessed by another database.
However, to support, for example, cross-application reporting, cross-database SELECT
queries are possible. This means that database objects, such as, tables and views, can be
local to one database but read by users from other databases in the same system.
Read-only queries between tenant databases are possible through the association of the
requesting user with a remote identity on the remote database(s). Cross-database access is
not enabled by default and must be configured before such user mappings can be set up.
A user in one database can run a query that references objects in another database if the user
is associated with a sufficiently privileged user in the remote database. This associated user is
called a remote identity. This is the user who executes the query (or part of the query) in the
remote database and therefore the user whose authorization is checked.
Note:
To enable cross-database access, you need the INIFILE ADMIN system privilege.

Figure 107: Cross Database Access Concept
Cross database-access enabling procedure

Let's say that we have a system with two tenant databases: DB1 and DB2.
Figure 108: Enable cross-database access
USER2 in DB2 wants to query the table SCHEMA1.TABLE1 in DB1, for example,
SELECT * FROM DB1.SCHEMA1.TABLE1
1. On the Database Overview page of the system database in the SAP HANA cockpit, open
the Manage Database Configuration app.
2. Change the value of the cross_database_access - enabled parameter in the global.ini

configuration file to true.

Lesson: Describing Cross-Database Authorizations in Tenant Databases
Alternatively, enable cross-database access by executing the following statement in the

system database:
ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') set
('cross_database_access', 'enabled')='true' WITH RECONFIGURE;
3. Enable communication from one tenant database to one or more other tenant databases
by executing the following statement in the system database:
ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') set
('cross_database_access', 'targets_for_DB2')='DB1' WITH RECONFIGURE;
4. The administrator of DB1 creates a user in DB1 with a remote identity in DB2
(alternatively, they define a remote database identification for an existing user).
CREATE USER USER1 WITH REMOTE IDENTITY USER2 AT DATABASE DB2
ALTER USER USER1 ADD REMOTE IDENTITY USER2 AT DATABASE DB2
5. The administrator of DB1 grants USER1 the privileges required to read the table
SCHEMA1.TABLE1.
6. Now, USER2 in DB2 can select from SCHEMA1.TABLE1 in DB1.
Note:
Only step 4 from the above listing must be done with SQL. All other steps can
be performed with the SAP HANA Cockpit.
Figure 109: Configure cross-database access direction
Generally, users receive the "Not authorized" error if they attempt a cross-database operation
that is not supported by the current configuration. However, if your configuration follows the
official documentation, then the error is caused by a missing restart of the SAP HANA system.

Note:
For more information, see SAP Note: 3048024 - Executing a Cross-Database
Access Query Fails with Error SAP DBTech JDBC: [258]: insufficient privilege: Not
authorized.
Things to Note About Remote Identities

The following should be noted in regards to remote identities:
● A user can be the remote identity for only one user in another database.
● An existing user can be assigned a remote identity using the ALTER USER statement.
ALTER USER <TargetDB_Username> ADD REMOTE IDENTITY <SourceDB_Username>
AT DATABASE <SourceDB>
● The association between a user and a remote identity is unidirectional.
● Only the SELECT privileges of the user in the remote database are considered during a
cross-database query. Any other privileges the remote user may have are ignored.
● Before users with remote identities can be created, an administrator must enable cross-
database access for the system in the system database and specify which databases can
communicate with one another.
● Users receive a Not authorized error if they attempt a cross-database operation that is
not supported by the current configuration.
Note:
LDAP group authorization is not supported for cross-database queries between
tenant databases. The remote identity of a user must be authorized using the
standard mechanism.
Monitoring Cross-Database Authorization

The following system views contain information about cross-database authorization in a
tenant database:
SYS.M_INIFILE_CONTENTS
This system view in the system database, shows whether the cross_database_access -
enabled parameter in the global.ini file contains the TRUE or FALSE value. It also displays
the communication direction between the source and the target database (if configured).
SELECT * FROM SYS.M_INIFILE_CONTENTS WHERE SECTION =
'cross_database_access' AND FILE_NAME = 'global.ini'
SYS.USERS
The HAS_REMOTE_USERS column indicates whether or not a particular user in the local
database has remote identities in other databases.
SELECT USER_NAME, HAS_REMOTE_USERS FROM SYS.USERS WHERE
HAS_REMOTE_USERS = 'TRUE'
SYS.REMOTE_USERS

Lesson: Describing Cross-Database Authorizations in Tenant Databases
This system view shows which local users can be used by users on other databases for
cross-database query execution.
SELECT * FROM REMOTE_USERS
Note:
The system views EFFECTIVE_PRIVILEGES and ACCESSIBLE_VIEWS do not
include privileges that a user has through a remote identity.
Troubleshoot cross-database access

Using cross-database access to query data from other tenant databases in your system,
some error situations may arise.
1. You are creating views, procedures, or synonyms to access objects on other tenant
databases in the same system. After dropping and re-creating an object on a remote
tenant database, you can no longer access the view or procedure on the local tenant
database. You get error messages, such as, invalidated view or invalidated
procedure. You also notice that the IS_VALID column in the system views VIEWS and
PROCEDURES do not accurately reflect the fact that the view or procedure is invalid. In
addition, there are entries missing in the OBJECT_DEPENDENCIES system view for the
affected views, procedures, or synonyms.
Cross-database access only supports read-only operations. Changes to an object on one
tenant database cannot therefore be reflected accurately on other tenant databases that
contain objects dependent on the changed object. This affects the validity flag in the
relevant system views, as well as the object dependencies. Remote objects may stay valid
if they retain their internal object identifier during re-creation and are re-created in an
compatible way, but they will become invalid if their internal object identifier changes.
Re-create the dependent object in the local tenant database in order for it to become valid
again.
2. You are querying an SQL view or a calculation view on a remote tenant database and the
view itself accesses objects on a third tenant database (multi-level cross-database
access). You are getting error messages, such as, insufficient privilege: not
authorized. Analytic privileges on the third tenant database may be evaluated based on
the wrong database user.
Cross-database queries do not support multiple tenant database levels as part of a view
hierarchy, even if communication between databases is enabled (including the required
authorized remote users).

Note:
For more information see:
● SAP Note 2426335 - Cross Database access within Multitenant DB's returns
error Insufficient privilege: Not authorized.
● SAP Note 3048024 - Executing a Cross-Database Access Query Fails with
Error SAP DBTech JDBC: [258]: insufficient privilege: Not authorized.
● Troubleshooting Error Situations Related to Cross-Database Access section in
the SAP HANA Administration Guide for SAP HANA Platform.
LESSON SUMMARY

Unit 7
Learning Assessment
1. In a SAP HANA system, the SYSTEM user is shared across all the tenant databases to
allow shared system administration.
X True
X False
2. Which SQL Statement is possible in a cross-database connection?

X A SELECT
X B INSERT
X C UPDATE
X D DELETE

Unit 7
1. In a SAP HANA system, the SYSTEM user is shared across all the tenant databases to
allow shared system administration.
X True
X False
That is correct. Every tenant database is self-contained with its own isolated set of
database users.
2. Which SQL Statement is possible in a cross-database connection?

X A SELECT
X B INSERT
X C UPDATE
X D DELETE
That is correct. To support for example cross-application reporting, cross-database

SELECT queries are possible.

UNIT 8 Analyzing users and
authorizations
Lesson 1
Tracing authorization errors 161
Lesson 2
Viewing Information about Users and Authorizations 167
UNIT OBJECTIVES
● Trace authorization errors

● View information about users and authorizations

Unit 8: Analyzing users and authorizations

Unit 8
Lesson 1
Tracing authorization errors
LESSON OBJECTIVES
Tracing Authorization Errors

While working with authorizations, it is common to deal with missing authorization errors. As
the missing privileges are not shown in the error message, the easiest way to identify the
missing privileges is to perform an authorization trace.
To manage authorization traces, the TRACE ADMIN system privilege is required. It is also
useful to have access to DATA ADMIN or CATALOG READ to further analyze the missing
privileges for the user, with the help of the system views, such as, EFFECTIVE_PRIVILEGES or
GRANTED_PRIVILEGES.
Figure 110: Authorization Trace Requirements
When a user is not authorized to perform an operation and receives an "insufficient privilege"
error, it is often difficult to know which privilege or privileges the user is in fact missing. Many
"insufficient privilege" errors therefore also return a GUID that allows you as an administrator
to identify the missing privilege. You can then decide whether to grant the privilege to the
user.
To resolve a missing authorization error, the following process is recommended:
1. Activate the trace for a specific user
2. Ask the user to reproduce the issue
3. Deactivate the trace

4. Analyze the trace file
Note:
We recommend deactivating the trace as soon as the issue is reproduced to avoid
any performance impact on the system.
To configure a user-specific tenant database authorization trace: Activate the trace for a
specific database user in the Database Explorers Trace Configuration screen and set the trace
level “Info” for the component Indexserver: Authorization.
Tracing Authorization Errors in the SAP HANA Database Explorer
Figure 111: Configuring Trace (I)
1. To configure the authorization tracing in the SAP HANA Database Explorer, right-click on
the database root node and choose Trace Configuration.
2. In the User-Specific Trace area, choose Add to activate the authorization trace for a
specific user.
Figure 112: Configuring Trace (II)

Lesson: Tracing authorization errors
3. Enter any name for Context Name in the user-specific trace configuration. You will use this
name later to identify the correct trace file for review.
4. In the Database User field, enter the name of the database user you want to monitor.
5. Search for authorization to identify the proper search components.
6. Switch the trace level to "INFO" for such components.
7. When you choose OK, a new trace configuration is created.
Figure 113: Checking Trace Files
8. As soon as you want to check the trace information, in the Database Explorer, navigate to
Database Diagnostic Files → [hostname] → indexserver of your tenant database.
9. In the Search TraceHostService field, search for the proper file using the context name you
indicated in the trace configuration.
10. Open and review the file.
Display information about missing privileges by using the associated GUID

If an insufficient privilege error occurs, you can find out more information about the missing
privilege by using the associated GUID.
To identify the missing privilege using a GUID, you need execute privilege for the following
procedure:
SYS.GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS('', ?)
Note:
Not all "insufficient privilege" errors can be resolved by granting the user a missing
privilege, for example, some operations can only be performed by the SYS user. In
these cases, the error message provides the explanation.
Caution:
In some cases, no GUID is returned. To resolve these errors, you need to perform
an authorization trace.

If the user lacks several privileges, only the first missing privilege that was found during the
authorization check is returned. You can find out what other permissions are missing by
running GET_INSUFFICIENT_PRIVILEGE_ERROR_DETAILS on the GUID that is returned on
each subsequent error message.
The details of every "insufficient privilege" error due to missing user privileges are stored in an
internal table for 144 hours by default. The number of entries in this table is limited to 10,000.
This configuration is controlled by the following parameters in the authorization section of the
global.ini file:
● insufficient_privilege_error_details_retain_duration
● insufficient_privilege_error_details_retain_records
Figure 114: Identify the missing privilege using a GUID
1. If a database user experiences an "insufficient authorization" error, the system

administrator should be notified. The system administrator must first find out which
authorizations are required by the user who is executing the instruction. The system
administrator can then decide whether the missing authorizations should be assigned to
the user.
2. Make a note of the GUID shown in the error message.
3. In either the Security and User Management or All view, navigate to the Insufficient
Privilege Details card, specify the GUID and choose Enter.
Note:
The missing privilege is displayed with the session user name and the checked
user name. Optionally, the object name, schema name, and object type are
displayed.
If the missing privilege is contained in one or more roles, the roles are
displayed.
4. Decide whether to assign the missing privilege or a role to the user.

Lesson: Tracing authorization errors
To assign the missing privilege to the user:

● Choose Assign Privilege → You are prompted to select the privilege, and assign it using the
privilege editor.
To assign a role containing the missing privilege:

● Choose Assign Role → This function is only available if the current user is able to grant the
role to the specified user.
Note:
For more information, see SAP Note: 1809199 - SAP HANA DB: Debugging user
authorization errors.
Checking Privileges Assigned to a User

Once the missing privilege is identified, it is useful to analyze what current privileges are
granted to the user, or on which roles the missing privilege is included. All this information can
be found on system views, such as, EFFECTIVE_PRIVILEGES, GRANTED_PRIVILEGES, and
STRUCTURED_PRIVILEGES.
Figure 115: Additional Information
LESSON SUMMARY


Unit 8
Lesson 2
Viewing Information about Users and
Authorizations
LESSON OBJECTIVES
User and Authorization Reporting

You can query several tables and system views to get detailed information about the exact
privileges and roles that users have and how they came to have them. This can help you to
understand why a user is authorized to perform particular actions and access particular data.
You must have the CATALOG READ system privilege to query the following views.
Figure 116: System Tables and Monitoring Views
The M_CONNECTIONS system view contains additional information about the authentication
method:
SELECT USER_NAME, AUTHENTICATION_METHOD FROM M_CONNECTIONS
By default, users can only query their own information.

The USERS system view lists all database users and provides lots of valuable information,
such as,LAST_PASSWORD_CHANGE_TIME, IS_KERBEROS_ENABLED, and IS_SAML_ENABLED.
As privileges can be assigned directly or inherited using roles, it is often difficult to define
which privileges a user has been granted. To provide better support, the
EFFECTIVE_PRIVILEGES view was created.

Note:
When selecting from the EFFECTIVE_PRIVILEGES view, you always need the
USER_NAME = 'something' condition in the WHERE clause; otherwise the
query will return with an error.
Figure 117: Display Privileges Granted to a User
The EFFECTIVE_ROLES system view displays the roles of the currently logged-on user. It
shows both roles that were granted directly to the user, and roles that were inherited from
other roles.
This system view complements the EFFECTIVE_PRIVILEGES system view.
Figure 118: Display Roles Granted to a User
The SAP HANA Cockpit provides the Authorization Dependency Viewer, to help troubleshoot
authorization errors and to analyze database objects and their dependencies that typically

Lesson: Viewing Information about Users and Authorizations
have complex dependency structures, like stored procedures, tables, and views. You need the
CATALOG READ system privilege.
For more information about resolving authorization errors with the authorization dependency
viewer, see Security and User Management View → User and Role Management → Managing
User Authorization → Resolve Object Authorization Errors in the SAP HANA Administration
with SAP HANA Cockpit Guide.
Figure 119: Dependency Viewer
The Authorization Dependency Viewer is a graphical tool that shows the object dependency
chains of stored procedures and calculation views together with the SQL authorization status
of the object owner. The Authorization Dependency Viewer shows you which privileges are
missing. This can be a first step to resolving issues with authorizations, invalid objects for
stored procedures, or calculation views with complex dependency structures, that are
preventing operations from being performed.
To open the Authorization Dependency Viewer app, in the Database Overview screen, go to the
User & Role Management card, then choose the Authorization Dependency Viewer link.
You can use the Authorization Dependency Viewer to analyze the following object types:
● NOT AUTHORIZED (258)
● INVALIDATED VIEW (391)
● INVALIDATED PROCEDURE (430)
Authorization or invalid object errors occur if the object owner does not have all the required
privileges on all underlying objects on which the object depends. The object owner must have
both the appropriate SQL object privilege (for example, EXECUTE, SELECT) and the
authorization to grant the object privilege to others (that is, WITH GRANT OPTION is set to
TRUE).
Hint:
Use the Authorization Dependency Viewer only with procedures that have the
DEFINER security mode. Procedures with the INVOKER security mode are not
validated correctly.

LESSON SUMMARY

Unit 8
Learning Assessment
1. Which privilege allows you to manage authorization traces?

X A USER ADMIN
X B ROLE ADMIN
X C TRACE ADMIN
X D RESOURCE ADMIN
2. Information about users and authorizations is stored in database views that are accessible
for reporting.
X True
X False
3. SAP HANA cockpit provides a graphical feature to help troubleshoot authorization errors.
X True
X False

Unit 8
1. Which privilege allows you to manage authorization traces?

X A USER ADMIN
X B ROLE ADMIN
X C TRACE ADMIN
X D RESOURCE ADMIN
This is correct. The TRACE ADMIN privilege allows you to manage authorization traces.
2. Information about users and authorizations is stored in database views that are accessible
for reporting.
X True
X False
This is correct. Information about users and authorizations is stored in database views
that are accessible for reporting.
3. SAP HANA cockpit provides a graphical feature to help troubleshoot authorization errors.
X True
X False
This is correct. SAP HANA cockpit provides a graphical feature to help troubleshoot
authorization errors.

UNIT 9 Using Audit Logging
Lesson 1
Using Audit Logging 175
Lesson 2
Managing Audit Logging 185
UNIT OBJECTIVES
● Use audit logging

● Activate and Configure Auditing

Unit 9: Using Audit Logging

Unit 9
Lesson 1
Using Audit Logging
LESSON OBJECTIVES
Audit Logging Overview

Auditing allows you to monitor and record selected actions performed in the SAP HANA
database. You can configure auditing independently for each database. Changes to the
auditing configuration in one database have no effect on auditing in other databases in an SAP
HANA system.
Figure 120: Audit Logging Scenario
Although auditing does not directly increase your database's security, if wisely designed, it
can help you achieve greater security in the following ways:
● Uncover security vulnerabilities if too many privileges were granted to certain users
● Show attempts to breach security
● Protect the system owner against accusations of security violations and data misuse
● Allow the system owner to meet security standards
Auditing is implemented through the creation and activation of audit polices. An audit policy
defines the actions to be audited, as well as the conditions under which the action must be
performed to be relevant for auditing. For example, actions in a particular policy are audited
only when they are performed by a particular user on a particular object. When an action
occurs, the audit policy is triggered and an audit event is written to the audit trail.
To use the audit logging, it must first be activated for the database. It is then possible to
create and activate the required audit policies.

Figure 121: Audit Logging Infrastructure
You can use the SAP HANA cockpit or SQL commands to enable auditing, configure audit trail
targets, and create audit policies.
Audit Policies
An audit policy defines the actions to be audited, as well as the conditions under which the
action must be performed to be relevant for auditing. When an action occurs, the policy is
triggered and an audit event is written to the audit trail. Audit policies are database specific.
Audit Actions
An audit action is an action executed in the database by an SQL statement. For example, to
track user provisioning in your system, you create an audit policy that audits the execution of
the CREATE USER and DROP USER SQL statements.
Although most actions correspond to the execution of a single SQL statement, some actions
can cover the execution of multiple SQL statements. For example, the action GRANT ANY
audits the granting of multiple entities on the basis of the SQL statements GRANT PRIVILEGE,
GRANT ROLE, GRANT STRUCTURED PRIVILEGE, and GRANT APPLICATION PRIVILEGE.
Actions that are typically audited (Overview):
● Changes to user authorization

● Creation or deletion of database objects
● Authentication of users
● Changes to system configuration
● Access to or changing of sensitive information

Lesson: Using Audit Logging
Figure 122: Audit Logging Actions
Actions that are typically audited (Details):

● Changes to user authorization
- Create or drop user, and create or drop role
- Grant or revoke role
- Grant or revoke SQL privilege, system privilege, and analytical privilege
- Create or drop analytical privilege
- Create or drop and alter structured privilege
● Creation or deletion of database objects
● Authentication of users
- Create or drop and alter structured privilege
● Changes to system configuration
- Changes to system configuration, for example, .ini file
When you enable audit logging for configuration changes, the previous values of
parameters are written to the audit trail.
- Install license key
- Set system license or unset system license for all
- Changes to the data volume encryption
● Access to or changing of sensitive information
You can specify the following database objects to be audited:
- Tables
- Views
- Procedures
- Schema
Both write and read access to data can be recorded as follows:

- SELECT
- INSERT
- UPDATE
- DELETE
- EXECUTE
Note:
Both successful and unsuccessful actions can be recorded.
For a full list of all actions that can be audited, see the documentation for SQL access control
statement CREATE AUDIT POLICY in the SAP HANA SQL Reference Guide for SAP HANA
Platform.
Hint:
You can only audit actions that occur inside the database engine. If the database
engine is not online when an action occurs, it cannot be detected and, therefore,
cannot be audited. These actions include, for example, an upgrade of an SAP
HANA database instance, or direct changes to system configuration files using
operating system commands.
An audit policy can specify any number of actions to be audited, but not all actions can be
combined together in the same policy. Actions can be grouped in the following main ways:
● All auditable actions
You can include all actions performed by a specific user in a single policy. This covers all
actions that can be audited individually, but also actions that cannot otherwise be audited.
This type of policy is referred to as a firefighter policy and is useful if you want to audit the
actions of a particularly privileged user.
● Data manipulation actions (DML)
You can include any actions that involve data manipulation together in a single policy, for
example, actions that audit SELECT, INSERT, UPDATE, DELETE, and EXECUTE
statements on database objects. A policy that includes these actions requires at least one
target object that allows the actions in question. This type of policy is useful if you want to
audit a particularly critical or sensitive database object.
● Data definition actions (DDL)
Other action types, for example, actions that involve data definition, can only be combined
together in a single policy if they are compatible. For example, the action GRANT
PRIVILEGE can be combined with REVOKE PRIVILEGE but not with CREATE USER. The
action CREATE USER can be combined with DROP USER.

Caution:
The actions that are audited are limited to those that take place inside the
database engine while it is running. Therefore, system restart and system
recovery will not be audited.
Caution:
Create a firefighter policy only in exceptional circumstances, for example, to
check whether a certain user is being used for everyday work or if a support user
has been given access to the system. Firefighter policies may create large
amounts of audit data and significantly impact performance if they are used for
high-load users.
Note:
If an audited action that involves data manipulation was executed implicitly by a
procedure, the call to this procedure is audited together with the audited action. If
the action does not involve data manipulation, then an implicitly executed
procedure is not audited. For example, if there is an active audit policy that audits
the action of creating users, the execution of CREATE USER statements within
procedures will be audited but not the procedures themselves.
Audit Policy Parameters

In addition to the actions to be audited, an audit policy specifies parameters that further
restrict the number of events actually audited.
Figure 123: Audit Policy Parameters
Retention Period
For audit policies that are explicitly configured to write audit entries to an internal database
table, you can specify an audit retention period in days. Once the retention period has elapsed
for an audit entry, the audit entry is deleted. If you add a retention period to an existing audit
policy, all existing audit entries that exceed the retention period are deleted.

Note:
A retention period can only be specified for audit policies that explicitly use the
database table audit trail target. You cannot specify a retention period for audit
policies that use the default audit trail targets, even if the default audit trail target
is set to database table.
Audit Policies for Tenant Databases

Certain activities in tenant databases can be logged by audit policies created in the system
database.
In general, audit policies for monitoring and recording activity in a tenant database are
created in the tenant database with an audit that writes to a local database table. However,
certain activities in tenant databases may have a security impact on the system as a whole.
These activities can be monitored and recorded from the system database.
A user in the system database with the DATABASE ADMIN or DATABASE AUDIT ADMIN
system privilege can create audit policies for a tenant database.
Figure 124: Audit Policy for Tenant Databases
Audit policies created in the system database for a tenant database are visible in the tenant
database through the AUDIT_POLICIES system view. The column IS_DATABASE_LOCAL
identifies where the audit policy was created, either locally in the tenant database or in the
system database. In the system database, it is possible to see all audit policies created in the
system database (for both the system database and all tenant databases) through the
AUDIT_POLICIES view of the SYS_DATABASES schema.
Administration users in the tenant database cannot change or delete audit policies created in
the system database for the tenant database, nor can they access the audit trail. Events
audited by these policies are written to the audit trail defined in the system database.

Actions Audited by Default Audit Policy

If auditing is active, certain actions are always audited and are therefore not available for
inclusion in user-defined audit polices. These actions are audited by the internal audit policy:
MandatoryAuditPolicy.
The actions listed below are always audited and result in audit entries with the CRITICAL audit
level. Audit entries are written to the audit trail configured for this audit level. If no audit trail is
configured for the CRITICAL audit level, entries are written to the audit trail configured for the
database.
Default Audit Policy
● Creation, modification, or deletion of audit policies

● Deletion of audit entries from the audit trail
This only applies to the audit trail written to an internal database table.
● Changes to auditing and authentication configuration:
- Enabling or disabling auditing
- Changing the audit trail target
- Changing the location of the audit trail target if it is a CSV text file
- Changing the maximum length of a statement that is audited completely
- Changing enabled authentication methods
● Changing the password of the SYSTEM user of a tenant database from the system
database
Audit Trails
When an audit policy is triggered, that is, when an action in the policy occurs under the
conditions defined in the policy, an audit entry is created in one or more audit trails.
The following audit trail targets are supported for production systems:
Figure 125: Audit Trail Targets
Internal database table

Using an SAP HANA database table as the target for the audit trail makes it possible to query
and analyze auditing information quickly. It also provides a secure and tamper-proof storage
location. Audit entries are only accessible through the public AUDIT_LOG and
XSA_AUDIT_LOG system views, and the union of these two views: ALL_AUDIT_LOG. Only

SELECT operations can be performed on this view by users with the AUDIT OPERATOR,
AUDIT ADMIN, or AUDIT READ system privilege.
If a database table is explicitly configured as the audit trail target of an audit policy, you can
define a retention period in the audit policy after which audit entries are automatically
deleted. It is also possible to delete old audit entries by truncating the table. You can do this in
the SAP HANA Cockpit or with the ALTER SYSTEM CLEAR AUDIT LOG SQL statement. The
system monitors the size of the table with respect to the overall memory allocation limit of the
system and issues an alert when it reaches defined values (by default 5%, 7%, 9%, and 11% of
the allocation limit). This behavior can be configured with check 64 ("Total memory usage of
table-based audit log"). Only users with the AUDIT OPERATOR system privilege can truncate
the audit table.
Logging system of the Linux operating system (syslog)

The syslog is a secure storage location for the audit trail because not even the database
administrator can access or change it. There are also numerous storage possibilities for the
syslog, including storing it on other systems. In addition, the syslog is the default log daemon
in UNIX systems. The syslog therefore provides a high degree of flexibility and security, as
well as integration into a larger system landscape. For more information about how to
configure syslog, refer to the documentation of your operating system.
Caution:
If the syslog daemon cannot write the audit trail to its destination, you will not be
notified. To avoid a situation in which audited actions are occurring, but audit
entries are not being written to the audit trail, ensure that the syslog is properly
configured and that the audit trail target is accessible and has sufficient space
available.
CSV text file

A separate CSV file is created for every service that executes SQL.
By default, CSV files are written to the same directory as trace files (/usr/sap/<sid>/
<instance>/<host>/trace). This means that database users with the DATA ADMIN,
CATALOG READ, TRACE ADMIN, or INIFILE ADMIN system privilege, can access them. In the
SAP HANA database explorer, they are listed under Database Diagnostics Files and at
operating system level; any user in the SAPSYS group can access them.
CSV audit trail files are created for each server in a distributed database system. For a holistic
view, you need to merge the individual files in a distributed setup.
Note:
Additionally, the option exists to write the audit trail to a kernel trace file (*.ltc)
in the trace directory (/usr/sap/<sid>/<instance>/<host>/trace).
The kernel trace output is not human-readable. It must be converted into a CSV
file using the command-line tool hdbltracediag and then loaded into relational
tables for SQL analysis.
hdbltracediag is available on the SAP HANA server at /usr/sap/<sid>/
HDB<instance>/exe.

Multiple Audit Trails

Separate audit trail targets may be configured for the audit level, that is the severity of the
action being audited and for an audit-policy.
Definition of Audit Trails on three different levels
● General audit trail target on

● Severity-specific audit trail target(s)
● Policy-specific audit trail target(s)
Audit entries from audit policies with the audit level EMERGENCY, CRITICAL, or ALERT are
written to the audit trail target(s) specified for the audit level in question. If no audit trail target
is configured for an audit level, entries are written to the audit trail target configured for the
database.
Audit policy-specific targets are also possible in the system database. In this case, audit
entries from a particular policy are written to the specified audit trail target(s). If no audit trail
target is configured for an audit policy, entries are written to the audit trail target for the audit
level if configured, or the audit trail target configured for the database. Several audit trail
targets can be configured for each individual policy.
You can optionally configure one or more policy-specific audit trail targets. If you do not
configure a policy-specific audit trail target, audit entries generated by the policy are written
to the audit trail target for the audit level of the policy if configured, or the audit trail target
configured for the system.
Note:
If an action is audited by multiple audit polices and these audit policies have
different audit trail targets, the audit entry is written to all trail targets.
Audit Trails for Tenant Databases

By default, tenant database administrators cannot configure audit trail targets independently
for their database since the underlying system properties are in the default configuration
change blacklist (multidb.ini). This means that they cannot initially be changed in tenant
databases, they must be changed from the system database.
The default target for all audit trails in tenant databases is internal database table. Although
not recommended, it is possible to change the audit trail target of a tenant database in the
following ways:
● The system administrator changes the audit trail targets for individual tenant databases
directly by configuring the relevant system property ([auditing configuration]
*_audit_trail_type) in the global.ini file. For more information about the system
properties for configuring audit trail targets and the configuration change blacklist in the
SAP HANA Security Guide.
● The system administrator removes the relevant system property ([auditing
configuration] *_audit_trail_type) from the configuration change blacklist, thus
enabling the tenant database administrator to change the audit trail target.

Caution:
To ensure the privacy of tenant database audit trails, it is recommended that you
do not change the default audit trail target (internal database table) of tenant
databases.
LESSON SUMMARY

Unit 9
Lesson 2
Managing Audit Logging
LESSON OBJECTIVES
Activate Auditing and Create an Audit Policy

The auditing feature of the SAP HANA database allows you to monitor and record selected
actions performed in your database. To be able to use this feature, it must first be activated
for the database. It is then possible to create and activate the required audit policies. You can
do this on the Auditing page of the SAP HANA cockpit.
Figure 126: Configuring Audit Logging
Configure the Base Setup for Audit Policies

You can use a wizard to quickly apply a basic configuration for audit policies. Instead of
manually configuring audit policies, you can use a wizard to apply SAP's recommended
configuration settings. This allows you to quickly start working with audit policies.
For a registered database, the UI notifies you if audit policy configuration was not completed
using the base setup wizards. You have the option to disable these notifications.

Figure 127: Base Setup for Audit Policies I
Figure 128: Base Setup for Audit Policies II
Note:
The base setup does not guarantee that the configuration is optimal for your
particular system. To optimize the configuration, it may be advisable to manually
configure specific settings.

Lesson: Managing Audit Logging
Figure 129: Recommended Set of Audit Policies
Audit Policies
An audit policy defines the actions to be audited, as well as the conditions under which the
action must be performed to be relevant for auditing. When an action occurs, the policy is
triggered and an audit event is written to the audit trail. Audit policies are database specific.
You can create audit policies on the Auditing page of the SAP HANA cockpit.
You can specify any number of actions to audit in an audit policy. Not all actions can be
combined together in the same policy; therefore, compatible audit actions are grouped
together. When you select an action, any actions that are incompatible with the selected
action are unavailable for selection.
If you want to select two incompatible audit actions, you need to create two separate audit
policies.
Figure 130: Create Audit Policies
In addition to the actions to be audited, an audit policy also specifies additional parameters
that further narrow the number of events actually audited, as follows:
● Audited action status

- On successful execution
- On unsuccessful execution
- On both successful and unsuccessful execution
● Target object or objects
- Tables
- Views
- Procedures
● Audited user or users
- Individual users can be included or excluded from an audit policy.
● Audit level
- EMERGENCY
- ALERT
- CRITICAL
- WARNING
- INFO
When an audit policy is triggered (that is, when an action in the policy occurs under the
conditions defined in the policy) an audit entry is created in the audit trail.
Firefighter logging logs all actions performed by a specific user. This covers all actions that
can be audited individually, as well as actions that cannot otherwise be audited. This type of
policy is useful if you want to audit the actions of a particularly privileged user.
Create Audit Policies for Tenant Databases from the System Database
You can audit specific tenant database activities from the system database.
In general, audit policies in a tenant database are created from within the tenant database. In
some scenarios like hosting you might want to centrally monitor activities in tenant
databases.
Audit policies created in the system database for a tenant database are visible in the tenant
database but cannot be changed from there.
View Audit Trail

For each occurrence of an audited action, one or more audit entries are written to the audit
trail. If the audit trail target is a database table, you can view the log on the Auditing page of
the SAP HANA cockpit. It is also possible to view the audit logs of the XS advanced runtime
environment. The layout of audit entries varies depending on the audit trail type.

Figure 131: Audit Log Analysis in SAP HANA Cockpit
Note:
The layout of audit entries varies depending on the audit trail type.
You can configure the audit trail view by clicking the Settings icon.
When a database table is the trail target, audit entries are accessible through the public
AUDIT_LOG and XSA_AUDIT_LOG system views, as well as the union of these views:
ALL_AUDIT_LOG. The table below describes the layout of the full audit trail: ALL_AUDIT_LOG.
Figure 132: Viewing the Audit Trail from the Database Table

Note:
Only SELECT operations can be performed on these views by users with the
AUDIT OPERATOR, AUDIT READ, or AUDIT ADMIN system privilege. AUDIT READ
also allows access to the AUDIT LOG table.
Figure 133: Viewing the Audit Trail from the SYSLOG
Caution:
If the syslog daemon cannot write the audit trail to its destination, you will not be
notified. To avoid a situation in which audited actions are occurring, but audit
entries are not being written to the audit trail, ensure that the syslog is properly
configured and that the audit trail target is accessible and has sufficient space
available.
Monitor the Size of the Audit Trail Table

To avoid the audit table growing indefinitely, you can delete old audit entries by truncating the
table. The system monitors the size of the table in relation to the overall memory allocation
limit of the system. It issues an alert when it reaches defined values, which are 5%, 7%, 9%,
and 11% of the allocation limit, by default. Configure this behavior can be configured with
check 64, Total memory usage of table-based audit log. Only users with the AUDIT
OPERATOR system privilege can truncate the audit table.
Note:
This alert only applies if you select a database table as an audit trail target (not for
syslog).

Caution:
If the table has grown so large that there is not enough memory to delete old
entries, use the following SQL command to empty the table completely: ALTER
SYSTEM CLEAR AUDIT LOG ALL. However, even if you archived the audit table
beforehand (recommended), any new entries written between the time of
archiving and the time of clearing may be lost.
You can use the SAP HANA cockpit to delete audit entries created up until a certain time from
the audit table.
For audit policies that are explicitly configured to write audit entries to an internal database
table, you can specify an audit retention period in days. Once the retention period has elapsed
for an audit entry, the audit entry is deleted. If you add a retention period to an existing audit
policy, all existing audit entries that exceed the retention period are deleted.
The minimum default retention period is seven days.
Figure 134: Audit Retention Policy
Note:
A retention period can only be specified for audit policies that explicitly use the
database table audit trail target. You cannot specify a retention period for audit
policies that use the default audit trail targets, even if the default audit trail target
is set to database table.
Note:
If you add a retention period to an existing audit policy, all existing audit log entries
that exceed the retention period will be deleted.

Note:
Prior to SAP HANA 2.0 SPS04, you could only delete all audit entries that were
older than a specified date. By specifying retention periods per audit policy, you
can now fine-tune your retention management.
Best Practices and Recommendations for Creating Audit Policies

To reduce the performance impact of auditing, consider some basic guidelines for creating
audit policies.
● Create as few audit policies as possible. It is usually better to have one complex policy than
several simple ones.
● Use audit actions that combine other actions where possible.
● Create audit policies for DML actions only if required. Auditing DML actions impacts
performance more than auditing DDL actions.
● Do not create audit policies for actions that are automatically audited, for example
CREATE AUDIT POLICY. For a list of actions that are always audited, see the section on the
default audit policy in the SAP HANA Security Guide.
● Do not create audit policies for database-internal tables that are involved in administration
actions. Create policies for the administration actions themselves.
Note:
P_USER_PASSWORD is an internal database table that cannot be accessed by
any user, not even the SYSTEM. Changes in this table are carried out by
internal mechanisms, and not by DML operations. Do not include these tables
in an audit policy. Instead create an audit policy for changes to users (ALTER
USER action) instead.
● Create a firefighter policy (that is, a policy that audits all actions for a user) only in
exceptional circumstances, for example, to check whether a certain user is being used for
everyday work or if a support user has been given access to the system. Firefighter policies
may create large amounts of audit data and significantly impact performance if they are
used for high-load users.
Recommended Audit Policies

Once auditing is active in the database, certain actions are always audited in the internal audit
policy MandatoryAuditPolicy. In addition, consider the following recommendations.
At a minimum, we recommend that you create audit policies in development and production
systems to audit the following additional administrative activities:
● Changes to SAP HANA configuration files (*.ini files).

Audit action: SYSTEM CONFIGURATION CHANGE.
● Changes to users.
Audit actions: CREATE USER, ALTER USER, DROP USER .
● Changes to authorization.

Audit actions: GRANT ANY, REVOKE ANY.
● Changes to the SAP HANA license key

● Recovery of tenant databases
Figure 135: Best Practices for Audit Policies
Additional policies in production systems

In production systems, additional audit policies are usually required to log further activities as
defined by IT policy and to meet governance and legal requirements, such as, SOX
compliance.
We also recommend auditing not only successful events but unsuccessful events by defining
the ALL audit action status. Knowing about unsuccessful events might be a prerequisite to
discovering an attack on your system.
Caution:
SAP HANA audit policies are defined at the database level and cannot cover all
requirements for data protection and privacy. The business semantics of data
are part of the application definition and implementation. It is therefore the
application that "knows", for example, which tables in the database contain
sensitive personal data, or how business level objects, such as, sales orders, are
mapped to technical objects in the database.
LESSON SUMMARY


Unit 9
Learning Assessment
1. Which of the following actions are audited by default in SAP HANA?

X A Changes to system configuration
X B Deletion of audit entries from the audit trail
X C Installation of SAP HANA license
X D Changes to system configuration
X E Creation, modification, or deletion of audit policies
2. The auditing feature of the SAP HANA database allows you to solve authorization
problems.
X True
X False
3. When the audit trail is written to an internal SAP HANA table, the entries are automatically
deleted by default when they are one year old.
X True
X False

Unit 9
1. Which of the following actions are audited by default in SAP HANA?

X A Changes to system configuration
X B Deletion of audit entries from the audit trail
X C Installation of SAP HANA license
X D Changes to system configuration
X E Creation, modification, or deletion of audit policies
This is correct. The following actions are audited by default: deletion of audit entries from
the audit trail, and the creation, modification, or deletion of audit policies.
2. The auditing feature of the SAP HANA database allows you to solve authorization
problems.
X True
X False
This is correct. The auditing feature of the SAP HANA database does not allow you to
solve authorization problems.
3. When the audit trail is written to an internal SAP HANA table, the entries are automatically
deleted by default when they are one year old.
X True
X False
This is correct. When the audit trail is written to an internal SAP HANA table, the entries
are automatically deleted by default when they are one year old.

HA940 EN Col17

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HA940 EN Col17

Uploaded by

Copyright:

Available Formats

HA940

SAP HANA 2.0 SPS05 -

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

© Copyright. All rights reserved. iii

American English is the standard used in this handbook.

This information is displayed in the instructor’s presentation

Related or Additional Information

User interface control Example text

Window title Example text

iv © Copyright. All rights reserved.

vii Course Overview

1 Unit 1: Introducing SAP HANA Security

3 Lesson: Introducing SAP HANA

29 Unit 2: Using SAP HANA administration tools

31 Lesson: Using security administration tools

39 Unit 3: Managing users

41 Lesson: Comparing User Types

71 Unit 4: Implementing authorizations in the SAP HANA Database

73 Lesson: Describing object ownership rules

115 Unit 5: Setting up personal database user accounts

117 Lesson: Set up personalized database administrator users

125 Unit 6: Managing authentication

127 Lesson: Managing Authentication

149 Unit 7: Enabling cross-database authorization in tenant databases

151 Lesson: Describing Cross-Database Authorizations in Tenant

159 Unit 8: Analyzing users and authorizations

161 Lesson: Tracing authorization errors

173 Unit 9: Using Audit Logging

175 Lesson: Using Audit Logging

© Copyright. All rights reserved. v

© Copyright. All rights reserved. vii

● Describe basic features of SAP HANA

© Copyright. All rights reserved. 1

2 © Copyright. All rights reserved.

SAP HANA Overview

The SAP HANA Database

Figure 1: SAP HANA: The Platform for All Applications

© Copyright. All rights reserved. 3

Introducing the SAP HANA Database

Standard Database Interfaces

Introducing SAP HANA XS and Development Infrastructure

SAP HANA XS, Advanced Model

4 © Copyright. All rights reserved.

SAP HANA XSC Model

Describing Isolation of Database Tenants

© Copyright. All rights reserved. 5

Figure 2: Multiple-Container System

6 © Copyright. All rights reserved.

Figure 3: Database Isolation

© Copyright. All rights reserved. 7

8 © Copyright. All rights reserved.

Outlining Security Functions

Protecting Data from Unauthorized Access

● User and role management

© Copyright. All rights reserved. 9

Figure 4: Security Functions Overview

Figure 5: Access Channels

10 © Copyright. All rights reserved.

Figure 6: User Management

A bootstrapping user SYSTEM is created during installation. We recommend the creation of

Authentication and Single Sign-on

© Copyright. All rights reserved. 11

Figure 7: Authentication and Single Sign-On