Bridging SAP Authorization Models & Databricks : An Architecture Pattern for Security Migration

[sampurnosarkar]

Introduction

As organizations modernize their analytics platforms, migrating business data from SAP to modern Lakehouse architectures has become increasingly common. However, one critical aspect is often overlooked—security migration.

SAP's authorization model is built upon roles, authorization objects, organizational restrictions, and user-role assignments that collectively determine access to business data. Simply migrating the underlying data without preserving these access controls can lead to governance and compliance challenges.

Rather than directly exposing SAP security tables to downstream platforms, this article proposes a CDS View-based Security Semantic Layer that standardizes authorization metadata and provides a reusable foundation for enterprise security modernization initiatives.

In this article, we will explore the core SAP security tables involved in authorization management, design reusable CDS Views for metadata extraction, and architect a unified Security Semantic Layer for downstream consumers.

Figure 1: High-Level Security Metadata Extraction Architecture

Understanding SAP Authorization Metadata

SAP's authorization framework is built upon multiple layers of security metadata that collectively determine a user's access to business data. Unlike traditional role-based access control models, SAP combines user-role assignments, authorization objects, authorization values, and organizational restrictions to enforce security policies.

At a high level, the authorization flow can be represented as follows:

Figure 2: SAP Authorization Metadata Flow

The core SAP security tables involved in authorization management are:

SAP Table	Purpose
AGR_DEFINE	Stores role definitions and metadata
AGR_USERS	Stores user-to-role assignments
AGR_1251	Stores authorization objects, fields, and values
TOBJ	Stores authorization object metadata

Each table plays a specific role in defining who can access business data and under what conditions.

• AGR_DEFINE acts as the role master table and contains information about SAP roles.
• AGR_USERS maps SAP users to their assigned roles.
• AGR_1251 contains the actual authorization rules, including authorization objects, field values, and organizational restrictions.
• TOBJ provides semantic information about authorization objects used throughout the SAP authorization framework.

Together, these tables provide all the metadata required to design a reusable Security Semantic Layer for downstream analytics and governance platforms.

Why Only These Tables?

For most authorization migration and metadata extraction initiatives, these four tables provide the minimum and sufficient set of security metadata required to represent:

• Role Definitions
• User-to-Role Assignments
• Authorization Rules
• Organizational Restrictions
• Authorization Object Metadata

By standardizing the information contained within these tables, organizations can create a business-friendly representation of SAP's authorization model without directly exposing low-level SAP security structures to downstream consumers.

Designing CDS Views for Security Extraction

Directly exposing SAP authorization tables to downstream platforms may appear to be the simplest approach for security migration. However, tightly coupling external consumers to SAP's underlying security tables introduces maintainability and extensibility challenges.

A better approach is to introduce a reusable Security Semantic Layer using CDS Views that abstracts SAP's authorization model into business-friendly entities.

Why CDS Views?

CDS Views provide several advantages when designing authorization extraction frameworks:

• Semantic abstraction of SAP security metadata.
• Centralized authorization metadata management.
• Improved maintainability and extensibility.
• Reduced dependency on underlying SAP table structures.
• Reusability across multiple downstream consumers.

Instead of exposing raw SAP tables, CDS Views allow us to represent authorization metadata in a standardized and reusable format.

CDS View Architecture

The following architecture illustrates the proposed CDS View design.

Figure 3: CDS View Architecture 

Proposed CDS Views

CDS View	Source Table	Purpose
ZI_ROLE_MASTER	AGR_DEFINE	Role metadata
ZI_ROLE_USER_MAPPING	AGR_USERS	User-to-role mapping
ZI_ROLE_AUTHORIZATION	AGR_1251	Authorization rules and restrictions
ZI_AUTHORIZATION_METADATA	TOBJ	Authorization object metadata
ZI_SAP_SECURITY_MODEL	Composite CDS View	Unified security model

Recommended Development Sequence

The CDS Views should be developed in the following order:

1. ZI_ROLE_MASTER
2. ZI_ROLE_USER_MAPPING
3. ZI_ROLE_AUTHORIZATION
4. ZI_AUTHORIZATION_METADATA
5. ZI_SAP_SECURITY_MODEL

The Unified Security Model should consume all the previously created CDS Views and act as the canonical representation of SAP authorization metadata.

Unified Security Model

The final CDS View should expose a business-friendly representation of SAP's authorization framework.

Example:

By introducing a layered CDS View architecture, organizations can create a reusable and semantically rich Security Semantic Layer that simplifies authorization metadata extraction while remaining independent of any specific downstream technology.

Building the Security Semantic Layer

Once the CDS Views have been designed, the final step is to expose a Unified Security Model that can act as the single source of truth for SAP authorization metadata.

Rather than tightly coupling downstream systems to SAP's internal security tables, the Security Semantic Layer provides a standardized and reusable representation of roles, authorizations, and organizational restrictions.

Figure 4: Security Semantic Layer Architecture

The Security Semantic Layer enables organizations to:

• Standardize authorization metadata.
• Simplify downstream integrations.
• Decouple analytics platforms from SAP's internal table structures.
• Improve maintainability and extensibility of security metadata.

Since the Security Semantic Layer is technology agnostic, it can be leveraged by various analytics, governance, and modernization platforms without requiring changes to the underlying SAP authorization model.

5. Conclusion

Security migration should not be treated as an afterthought during enterprise analytics modernization initiatives. Authorization metadata is just as critical as business data and deserves the same level of architectural consideration.

By introducing a layered CDS View architecture and a reusable Security Semantic Layer, organizations can preserve SAP's mature authorization framework while simplifying future integrations with modern analytics and governance platforms.

Rather than exposing low-level SAP security tables directly, standardizing authorization metadata at the SAP layer provides a scalable, maintainable, and business-friendly foundation for enterprise security modernization initiatives.