18 SAP HANA XSA Security
SAP HANA extended application services, advanced model (SAP HANA XSA) is the next evolution of SAP HANA extended application services, classic model (SAP HANA XS). The new SAP HANA XSA provides a more robust application server environment that supports multiple runtimes and programming languages.
In this chapter we’ll take a closer look at the security structure of the SAP HANA XSA platform. We’ll first start with an overview of the SAP HANA XSA platform. We’ll then discuss SAP HANA XSA users, role collections, organizations, and spaces and describe how they are administered and secured. We’ll briefly discuss SAP Web IDE for SAP HANA, why it is needed, and how you’ll secure access to the application. Finally, we’ll review the architecture of the SAP HANA Deployment Infrastructure (HDI) container, discuss how runtime security works within the HDI container, explore how HDI container roles work, and show you how security administrators will manage runtime access to objects outside of an HDI container.
18.1 Overview of SAP HANA XSA
The SAP HANA extended application services, advanced model (SAP HANA XSA) platform provides a versatile and robust application server and development environment. The SAP HANA XSA platform was introduced with SAP HANA 1.0 SPS 11 as the demand for application development within a multi-target application (MTA) framework, with the Cloud Foundry platform, and with SAP’s software-as-a-service (SaaS) platform offerings was increasing. Part of the overall SAP HANA platform, SAP HANA XSA can be installed alongside the core SAP HANA database services.
With SAP HANA 2.0, the SAP HANA XSA framework has become the default and recommended framework for application development with SAP HANA. Still, rarely will you find an organization utilizing the SAP HANA XSA framework within an on-premise SAP HANA 2.0 deployment for a variety of reasons. Although SAP HANA XSA offers a significantly enhanced application development framework, it also greatly increases the complexity of development, administration, and security, based on our personal experience.
When SAP HANA was initially released, SAP HANA extended application services, classic model (SAP HANA XS ) was notable because SAP HANA XS was closely coupled with the database services within SAP HANA. This feature of SAP HANA, where the database was designed to do all the application’s data management and the web application server was simply designed to visualize results, is unique. Purely from an application development standpoint, this architecture had limitations. First, SAP HANA XS only provided a single repository and framework where applications could be deployed, which created challenges for organizations that had multiple versions of applications and for organizations that were hosting multiple development groups in a single SAP HANA instance.
However, outside of the application design paradigm, the SAP HANA XS repository provides a simple and elegant solution for managing database security and business intelligence-related content. In these two areas alone, the expanded functionalities of SAP HANA XSA are not necessary, and in most instances, SAP HANA XSA’s increased complexity and administration cost are not warranted.
The SAP HANA XSA framework is decoupled from the SAP HANA database. Figure 18.1 shows a basic overview of the architecture. Notice that the SAP HANA database is separate from the SAP HANA XSA platform. The SAP HANA XSA platform communicates with the SAP HANA database via SQL. Clients will access the SAP HANA XSA via HTTP/HTTPS. Most organizations will install SAP HANA XSA services on the same physical host as the SAP HANA index server, otherwise known as the core database service.
SAP HANA XSA is comprised of three distinct SAP HANA platform services: xscontroller, xsexecagent, and xsuaaserver. Each service performs different tasks within the SAP HANA XSA platform, and each service interacts with components of the SAP HANA database. In general, SAP HANA XSA services use SQL protocols to interact with the SAP HANA database. SAP HANA XSA will create and interact with objects in the database including users, schemas, tables, containers, roles, and other items.
As of SAP HANA 2.0 SPS 04, the SAP HANA XS framework, the _SYS_REPO user concept, the package hierarchy, and repository roles still technically all work. Tools such as the SAP HANA Web-Based Development Workbench editor are still functional under the SAP HANA XS services and can still be utilized to create repository-based roles and business intelligence content. Other tools like SAP HANA application lifecycle management are also available to help you transport content between SAP HANA systems.
Figure 18.1 Basic SAP HANA XSA Architecture
Finally, all the functionalities found in SAP HANA Studio work even with SAP HANA 2.0 SPS 04-based systems. In this book, much of our discussion is focused on solutions based on the SAP HANA XS model. This focus is because its replacement by the SAP HANA XSA framework does not currently provide enough control over security nor does it offer scalable security mechanisms to properly manage an SAP HANA database security model. Our hope is that SAP will address these gaps before the SAP HANA XS environment is removed from the platform.
With the SAP HANA XSA framework, SAP HANA development occurs within a service layer called the SAP HANA Deployment Infrastructure (HDI). While the infrastructure of an HDI container is quite different from the SAP HANA XS-based model, think of HDI containers in SAP HANA XSA as a replacement for the XS _SYS_REPO repository. An SAP HANA instance can only have a single XS _SYS_REPO repository. However, that same instance can support multiple HDI containers. This versatility allows you to both segregate one HDI container from another as well as deploy multiple versions of the same object into the same database instance. We’ll discuss HDI containers in more detail in Section 18.4.
In the subsequent sections of this chapter, we’ll review HDI containers and show you the mechanisms for securing the database artifacts that HDI containers produce. In the next section (Section 18.2), we’ll provide you an overview of the security mechanism of the SAP HANA XSA platform. Because SAP HANA XSA is largely decoupled from the database, it has its own independent authorization mechanism and organizational structure. Note that SAP HANA XSA shares users and authentication mechanisms with its associated tenant or SYSTEM database. Let’s look at the process you’ll use to govern the SAP HANA XSA platform.