Describing SAP HANA Authentication and Authorization


After completing this lesson, you will be able to:

  • User management in SAP HANA
  • Describe authentication methods in user management
  • Describe the authorization approach

User Management in SAP HANA Databases

In a system with multi-tenant database containers, there is a clear rule:

Each tenant database has its own database administrator accounts and end users. Privileges granted to users in a particular multi-tenant database container authorize operations in that database only.

An exception to this rule is given in the system database:

In case a user gets assigned the system privilege DATABASE ADMIN, this authorization allows them to execute operations on individual tenant databases, for example, to create or drop tenant databases, to change database-specific properties in configuration (*.ini) files, and perform database-specific backups.

The system database, as well as all tenant databases, has their own SYSTEM user. The SYSTEM user of the system database has already assigned the above mentioned system privilege DATABASE ADMIN.

In a multiple-container system, privileges granted to users in a particular database authorize access to and modification of database objects in that database only.

Cross Database Queries Between Multi-Tenant Database Containers

Every tenant database in a multiple-container system is self-contained with its own isolated set of database users and isolated database catalog. However, to support 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 be read by users from other databases in the same system.

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.

Cross-database access is not enabled by default and must be configured before such user mappings can be set up.

By default, cross database access between tenants is inactive. To run queries spanning multiple tenant databases, the global cross database access switch has to be turned on. An allowlist of databases that are permitted to communicate with each other also has to be set up.

For more information on this topic, read the section Cross-Database Authorization in Tenant Databases in the SAP HANA Security Guide for SAP HANA Platform.

Read-only queries between multi-tenant database containers are possible through the association of the requesting user with a remote identity on the remote database or databases. Cross-database queries (federation) are supported in the SQL engine and calculation engine.

User Access Channels

Authentication Methods

The identity of every database user accessing the database is verified through a process called authentication.

Authentication Methods

The protocol X.509 (version 3) has to be treated as an exception, because it cannot be used for the server authentication in combination with SQLDBC (JDBC/ODBC). Nevertheless, the client authentication is supported with a JDBC/ODBC client. See details in the SAP HANA Security Guide for SAP HANA Platform

The SAP HANA database provides the following options for authentication:

  • Direct logon to the SAP HANA database with user name and password

  • Authentication using Kerberos (third-party authentication provider)

  • Authentication using Security Assertion Markup Language (SAML) bearer token

  • Authentication using SAP Logon Ticket and SAP Assertion Ticket

  • Authentication using X.509 certificates

  • JSON Web Tokens (JWT)

Overview of Authentication Methods for SQLDBC and HTTP Access

When using direct logon to the SAP HANA database with user name and password, the SAP HANA database authenticates the user.

By default, all authentication mechanisms are enabled. However, you can 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 password,kerberos,spnego,saml,saplogon,x509xs,sessioncookie.


Some administrative operations, such as database recovery, also require the credentials of the SAP operating system user (<sapsid>adm).

Assign Authentication Method in SAP HANA Cockpit

When creating or changing a user account in the SAP HANA cockpit, there is a wide range of authentication mechanisms that can be assigned. In SAP HANA, authentication methods can be directly assigned to user accounts and every user can get assigned multiple methods.

The default authentication is the use of username and password. When the password is set, this indicates whether or not authentication for the username and password is enabled. For interactive users, a password change at the first logon might make sense. If the password option was flagged, the default setting Force password change on next logon is assumed, but can also be deactivated.

The only authentication method that works from scratch without further administrative adjustment is the username/password mechanism. All other options are more sophisticated authentication mechanisms (for example SAML, Kerberos, X509, and JWT) and need further configuration before being able to use them.

The authentication mechanisms Kerberos, Security Assertion Markup Language (SAML), X509 (IBM protocol), and JSON Web Token (JWT) are authentication standards and/or third party methods, while the usage of logon and assertion tickets are native SAP proprietary mechanisms.

Overview of external Authentication Methods

Some external authentication mechanisms need further software to be used in combination with SAP HANA.

For details, use cases, and configuration read the respective section and consult the SAP HANA Security Guide for SAP HANA Platform.

Kerberos Authentication

A user connecting to SAP HANA through Kerberos must have an SAP HANA database user. This database user is mapped to the external identity in a Key Distribution Center (KDC), such as Microsoft Active Directory.

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 SAP HANA extended application services, classic model, Kerberos authentication is enabled with Simple and Protected GSS-API Negotiation Mechanism (SPNEGO).

Kerberos is a network authentication protocol that provides authentication for client-server applications across an insecure network connection using secret-key cryptography.

ODBC and JDBC database clients support the Kerberos protocol. A prominent example of a client supporting this authentication method is the SAP HANA cockpit. You can also implement access from front-end applications 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.

There are two variants when using the Kerberos single sign-on mechanism for clients in combination with SAP HANA:

  • Direct authentication

    ODBC/JDBC clients connect from within a network to the key distribution center (KDC), get authenticated using a Kerberos ticket, which is forwarded to SAP HANA. If web browsers are used as clients, SAP HANA uses the XS implementation (typically XSA) to realize this mechanism.

  • Indirect authentication via constrained delegation

    In this scenario, the client first connects to the application, which itself is connected to the KDC and verifies the client by requesting a Kerberos ticket. This ticket in turn is sent to SAP HANA for authentication. There are multiple products (SAP-owned and non-SAP) using this indirect authentication via constrained delegation (for example, Smart Data Access and Hadoop).


For more information, see SAP Note 1837331 How To configure Kerberos SSO to SAP HANA DB using Microsoft Windows Active Directory.

Security Assertion Markup Language (SAML) Authentication

The SAP HANA database supports user logon to the SAP HANA database using Security Assertion Markup Language (SAML).

You can select SAML as a user authentication method when creating users in the SAP HANA cockpit.

Features of SAML

The features of SAML are as follows:

  • SAML is the XML-based standard for communicating identity information between organizations. The primary function of SAML is to provide Internet single sign-on (SSO) for organizations. Organizations use SAML to securely connect internet applications that exist both inside and outside the organization's firewall.

  • SAML is a standard protocol for authentication. Internet SSO is a secure connection that communicates identity and trust from one organization to another. For users, Internet SSO eliminates additional logons to external resources. For system administrators, it improves security and reduces costs.

    SAML requires a trusted third-party (identity provider) that can issue SAML assertions for clients (for example, a browser).

  • SSO in middleware or application server scenarios are as follows:

    • Whenever the application server needs to connect to the SAP HANA database on behalf of a user, it requests an SAML assertion from the client.

    • The SAML assertion is issued by the identity provider after the client is authenticated successfully, and is then sent to the SAP HANA database.

  • SAML restrictions are as follows:

    • The SAP HANA database can only act as an SAML service provider.

    • Assertions can be used for authentication only; there is no support for further properties.

You cannot use SAML for authorization.

The configuration page for SAML identity providers is located in the Configure SAML Identity Provider application from SAP HANA cockpit.


Previously, this configuration page was available in the system properties.

Configure SAML in SAP HANA

You can configure SAML providers for ODBC or JDBC-based SAML authentication using the SAP HANA cockpit or SQL statements. However, always use the SAP HANA extended application services administration tool to configure SAML providers that will be used for HTTP access via the classic SAP HANA extended application services server.

The main purpose of SAML for SAP HANA is to support scenarios where clients are not directly connected to the SAP HANA database, but to a middle-tier application server (SAP HANA extended application services engine, for example).

This middle-tier application server runs an HTTP server. Whenever the application server needs to connect to the database on behalf of the user, it requests an SAML assertion from the client.

The assertion is issued by an identity provider after the client is authenticated successfully. The assertion is then forwarded to the SAP HANA database, which grants access based on the previously established trust to the identity provider.

SAML Configuration in Administration of SAP HANA Extended Application Services

SAP HANA extended application services includes a Web-based administration tool. This tool enables you to configure several security-related aspects of applications for SAP HANA extended application services, including authentication (for example, enforced authentication mechanism, trust store configuration and management, and SAML configuration).

LDAP Group Authentication and Authorization

The Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing directory services. If you use an LDAP-compliant identity management server to manage users and their access to resources, you can use an LDAP server to authenticate SAP HANA users, and you can use LDAP group membership to authorize SAP HANA users.

Automatic User Provisioning Based on LDAP

SAP HANA can automatically create users if they already exist in an LDAP server. In combination with SAP HANA's ability to automatically assign roles to users based on LDAP groups, this can significantly reduce the complexity and cost for maintaining users and authorizations in large system landscapes.

LDAP Authentication

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.


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.

Creating a new user with LDAP authentication:

Code snippet

Enabling LDAP authentication for an existing user:

Code snippet
  • A user enabled for LDAP authentication can’t be enabled for password authentication.

  • LDAP authentication can’t be used for the SYSTEM user.

To enable LDAP user authentication, you set up a connection to an LDAP server by creating an LDAP provider in the SAP HANA database. Depending on your requirements, you configure the LDAP server to authenticate users only, or to authenticate and authorize users. For LDAP-authenticated users, you can also enable the automatic creation of users in SAP HANA.

LDAP Group Authorization

You can map LDAP groups to SAP HANA roles. This means that if SAP HANA users are configured for LDAP group authorization, SAP HANA can determine which roles to assign them based on their membership in one or more LDAP groups. The privileges defined in the SAP HANA role determine users' access to requested resources.

How Does LDAP Group Authorization Work?

The procedure for LDAP group authorization is as follows:

  1. The LDAP-enabled user logs on.
  2. SAP HANA queries the LDAP directory for group memberships.
    • The logon to SAP HANA succeeds if the user’s LDAP groups map to at least one SAP HANA role.

    • The logon to SAP HANA fails if the user is not a member of any LDAP groups, or if the groups are not mapped to any SAP HANA roles.

  3. SAP HANA grants the user roles according to the defined mapping.

    LDAP group memberships are cached (the default is four hours). However, you can configure the caching duration, for example, to force the LDAP group membership to be re-evaluated upon each user logon.

LDAP Group Authorization: Configuration

You must enable LDAP group authorization explicitly for users. The procedure for the configuration of LDAP group authorization is as follows:

  1. Map LDAP groups to SAP HANA roles.

  2. Configure the connection to the LDAP server.

  3. Configure authorization mode LDAP for SAP HANA users.

A role that has an LDAP group mapping can also be granted to users and other roles as usual. If the role is deleted, it is also revoked from users as usual. Mappings of LDAP groups to this role are also deleted.


TLS- or SSL-secured communication between SAP HANA and an LDAP server uses OpenSSL on the SAP HANA server side. The OpenSSL library is installed by default as part of the operating system installation.

SAP Logon Ticket and SAP Assertion Ticket

You can authenticate users in SAP HANA with logon or assertion tickets. These tickets are issued to users when they log on to an SAP system configured to create tickets (for example, the SAP NetWeaver Application Server).

If you want to integrate an SAP HANA system into a landscape that uses SAP logon or assertion tickets for user authentication, configure SAP HANA to accept logon or assertion tickets.

The section Configure Authentication Using SAP Logon Tickets and Assertions in the SAP HANA Security Guide for SAP HANA Platform can be used as a reference for configuration steps.

SAP HANA validates incoming logon or assertion tickets against certificates signed by a trusted Certification Authority (CA) stored in a dedicated trust store. This trust store must contain all root certificates used to validate logon and assertion tickets.

The user named in an incoming SAP logon ticket must exist as a database user. You must also configure the database user for authentication using logon or assertion tickets. You can configure the database users in the Manage users app of the SAP HANA cockpit.

For more information about using logon tickets, see the SAP NetWeaver Platform library:

User Authentication and Single Sign-On

JSON Web Tokens

JSON Web Token (JWT) is an open standard. SAP HANA validates tokens according to the IETF standard.


For restrictions and requirements of JWT refer to the following area in the SAP HANA Security Guide for SAP HANA Platform:

Single Sign-On Using JSON Web Tokens

JSON Web Tokens (JWT) can be used for user authentication in single sign-on environments. The identity of users can be authenticated by JWT tokens issued by a trusted identity provider. The following clients can be used in combination with JWT:

  • DB 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 (XSA)

A JWT can be used to authenticate users accessing SAP HANA directly from ODBC/JDBC database clients or indirectly through SAP HANA extended application services, advanced model (SAP HANA XS, advanced).


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.

Authorization Concept

All access to data and the execution of actions in the database requires authorization. Every user who wants to work directly with the SAP HANA database must have a database user with the necessary authorizations. This area is an important part of the overall authorization concept, which is covered in details in the SAP HANA Security Guide for SAP HANA Platform.

The focus of this lesson is to describe the big picture of the authorization framework in SAP HANA.

Authorizations Assigned by Privileges and Roles

Users log on to the SAP HANA database and can own database objects. The authorizations are assigned by roles and privileges.

Privileges define what users can see and do. 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 scheme and to model reusable business roles.

Roles are used to bundle and structure privileges for dedicated groups of users. Typical roles are defined for specific tasks, handle data models (create, activate, consume, and so on).

You can manage authorization for users using roles. You can nest roles so that role hierarchies can be implemented. This increases their flexibility, allowing for both precise and broad-scale authorization management for individual users.

All the privileges granted directly or indirectly to a user are combined. This means that 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.

You cannot explicitly deny privileges. This means that the system does not need to check all the user’s roles. Once all the requested privileges are located, the system aborts the check and grants access.

Several predefined roles exist in the database. Some of them are templates that need to be customized; others can be used as they are.

After a successful logon, the system verifies the user's authorization to perform the requested operations on the requested objects. This is determined by the privileges that the user has been granted. The user must have both the privilege to perform the operation and the privilege to access the object (for example, a table) to which the operation applies.

Privileges can be granted to database users either directly, or indirectly through roles. A role is a set of privileges. Roles are the standard mechanism of granting privileges because they allow you to implement both fine-grained and coarse-grained reusable authorization concepts that can be modeled on business roles. Several standard roles are also delivered with the SAP HANA database (for example, MODELING, MONITORING). You can use these as templates for creating your own roles.

User-Centric Authorization Approach

When accessing the SAP HANA database using a client interface (such as Open Database Connectivity [ODBC], Java Database Connectivity [JDBC], and Multidimensional Expressions [MDX]), any access to data must be backed by corresponding privileges. Different schemes are implemented. On a higher level, this concept provides authorization for the data contained in the database when it is accessed using client interfaces. In the SAP HANA database system, the regular SQL authorization concept is implemented.

For each SQL statement type (for example, SELECT, UPDATE, and CALL), the executing user needs to have a corresponding privilege. Also, objects in the database (such as tables, views, or stored procedures) have an owner who can access the objects and grant privileges for them.

No user can access this particular object, other than the owner of an object and users that the owner has provided with a privilege. This authorization operates at the object level, where the smallest entities that can be privileged are, for example, a table or a view.

In addition, analytic privileges provide row-level authorization for certain database objects, such as analytic views.

Managing Users and Roles

The process flow for user management is as follows:

  1. Define and create privileges.

  2. Define and create roles.

    Use the Manage users app in the SAP HANA cockpit or run the SQL statement CREATE ROLE <Role_Name>.

  3. Assign privileges to roles.

  4. Create users.

    Choose the following authentication methods:

    • Define the initial password.

    • Define the external User ID (for example, Kerberos to set up SSO).

    • Define other user settings.

    Define default client is used as an implicit filter value when reading from SAP HANA data models.

  5. Grant roles to users.

    Use the Manage users app in the SAP HANA cockpit or run the SQL statement GRANT <Role_Name> TO <user>.

    To revoke roles, use the SQL statement REVOKE <Role_Name> FROM <user>.

  6. Optional: Create groups.
  7. Optional: Assign roles to groups.
  8. Optional: Assign users to groups.
The enhancement with groups allows the use of further functions, such as a delegated user and/or role administration, and the use of individual group policies.For details, read User Groups in the SAP HANA Security Guide for SAP HANA Platform.

Password Policy Management

Passwords for the user name password authentication of database users are subject to certain rules. These are defined in the password policy and the password exclude list. You can change the default password policy according to your organization’s security requirements. You cannot deactivate the password policy.

If the user's password has expired, the user must change the password to a new value.

Password Policy

The password policy has the following conditions:

  • Password quality (length, complexity)

  • Password exclude list (forbidden terms)

    The password quality is defined by several parameters and the password exclude list can also be maintained in the Security and User Management area in the SAP HANA cockpit.

    The password exclude list is a list of words that are not allowed as passwords or parts of passwords. SAP HANA checks this exclude list whenever a password is created or changed. You can specify if the words in the exclude list are case-sensitive and if the check applies to whole words or parts of words. The password exclude list is implemented as table _SYS_PASSWORD_BLACKLIST in the schema _SYS_SECURITY. The owner of both the schema and the table is the user SYSTEM.

    Details on both topics can be found in the following guide: SAP HANA Security Guide for SAP HANA Platform in section Configure the Database Password Policy and Password Exclude List

    During the initial system setup, the SYSTEM user grants change privileges for this table to a dedicated administrator user.


    For security reasons, and to prevent users from viewing sensitive information such as a password, manage the privilege to select carefully.

Password Policy Parameters

The password policy is defined by parameters in the password policy section of the indexserver.ini system properties file.


The password policy parameters for the system database of a multiple-container system are maintained in the namesever.ini file, not the indexserver.ini file.

If a parameter is set to a value outside the value range, either the minimum value or the maximum value of the value range, whichever is appropriate, is used instead.

Configure Password Policy

The Authentication app in the SAP HANA cockpit allows you to view the password policy and to change its default configuration.


The user lock setting (parameter password_lock_time) defines the duration that a user is locked after the maximum number of failed logon attempts. If you select the Lock indefinitely checkbox, the user is locked indefinitely. This corresponds to a parameter value -1. The value 0 unlocks the user immediately.

The prerequisites for changing parameters are as follows:

  • System privilege INIFILE ADMIN

  • (For exclude list) INSERT and DELETE privileges for either the _SYS_PASSWORD_BLACKLIST table or the _SYS_SECURITY schema

To view the contents of the INI file, use the M_INIFILE_CONTENTS view.

The password policy parameters can be found in the M_PASSWORD_POLICY view.

Log in to track your progress & complete quizzes