SAP Authorization

Ga
Global Blueprint SAP Authorization Document Information Revision History Document Objective Provides the overview of the process area covered in this document and describes the Business Process Hierarchy (BPH) up to Level 4 (Activity). Describes key business requirements gathered during workshops with GAR Business Process Leads and key business users. Outline the solution and system design in SAP S/4HANA to address the business requirements in respective process area. This document serves as the global blueprint template to be used as the basis for S/4HANA implementation project Document Sign Off Sheet Solution Blueprint Order To Bill – Sales Processing and Fulfullment TAble of Contents 1 Enterprise Authorization Overview 8 1.1 Purpose 8 1.2 Enterprise Authorization Design Objectives 8 1.3 Enterprise Authorization Overview 9 1.4 Enterprise Authorization Architecture 10 1.5 Enterprise Authorization Guiding Principles 11 1.6 Enterprise Authorization Scope 11 1.7 Design Assumptions 12 1.8 Design Constraints 12 1.9 Success Criteria 12 2 Authorization Design Strategy 13 2.1 Design Strategy Overview 13 2.2 Authorization Design Philosophy 13 2.3 Enterprise Authorization Architecture 13 2.4 Authorization Layer Relationship 14 2.5 Authorization Assignment Strategy 14 2.6 Authorization Design Decision Matrix 14 2.7 Enterprise Authorization Design Standards 14 2.8 Enterprise Authorization Design Rules 15 2.9 Authorization Design Checklist 15 2.10 Authorization Design Anti-Patterns 16 2.11 Authorization Naming Strategy 16 2.11.1 Naming Objectives 16 2.11.2 Naming Principles 16 2.11.3 Naming Governance 17 2.11.4 Authorization Naming Scope 17 2.11.5 Naming Hierarchy 17 2.11.6 Naming Ownership 17 2.11.7 Naming Standards Reference 18 2.11.8 Naming Lifecycle 18 2.11.9 Naming Design Rules 18 3 BUSINESS ROLE DESIGN 18 3.1 Purpose 18 3.1.1 Design Objectives 19 3.1.2 Scope 19 3.1.3 Business Value 20 3.1.4 Guiding Principles 20 3.2 Business Role Concept 21 3.2.1 Definition 21 3.2.2 Business Responsibility 21 3.2.3 Characteristics 21 3.2.4 Business Role vs. Technical Role 22 3.3 Business Role Architecture 22 3.3.1 Architecture Overview 22 3.3.2 Design Philosophy 22 3.3.3 Architecture Principles 22 3.3.4 Relationship Model 23 3.4 Business Role Components 23 3.4.1 Mandatory Components 23 3.4.2 Mandatory Metadata 23 3.5 Business Role Naming Convention 24 3.5.1 Naming Objectives 24 3.5.2 Naming Structure 25 3.6 Business Role Design Principles 25 3.6.1 Business-Driven Design 25 3.6.2 Responsibility-Based Design 25 3.6.3 Reusability 26 3.6.4 Least Privilege 26 3.6.5 Standardization 26 3.6.6 Governance 26 3.6.7 Design Considerations 26 3.7 Business Role Assignment Strategy 27 3.7.1 Assignment Principles 27 3.7.2 Assignment Model 27 3.7.3 Assignment Rules 27 3.7.4 Assignment Validation 28 3.8 Business Role Ownership 28 3.8.1 Ownership Principles 28 3.8.2 Ownership Model 28 3.8.3 Ownership Responsibilities 29 3.8.4 RACI Matrix 29 3.9 Business Role Lifecycle 29 3.9.1 Lifecycle Stages 29 3.9.2 Lifecycle Description 30 3.9.3 Lifecycle Controls 30 3.9.4 Lifecycle Principles 30 3.10 Business Role Design Rules 31 3.10.1 Design Rule Compliance 31 3.11 Business Role Design Checklist 31 3.11.1 Design Validation Checklist 31 3.11.2 Implementation Readiness Checklist 32 3.11.3 Periodic Review Checklist 32 3.12 Business Role Anti-Patterns 32 3.12.1 Common Anti-Patterns 33 3.12.2 Anti-Pattern Detection 33 3.13 Business Role Examples 33 3.13.1 Example Business Role Mapping 33 3.13.2 Relationship Example 34 3.13.3 Assignment Example 34 Enterprise Authorization Overview This chapter establishes the foundation of the Enterprise Authorization Design adopted for the S/4HANA Transformation Project. It explains why the authorization model is required, the business objectives it supports, and the architectural concepts that will be applied consistently throughout the remaining chapters of this blueprint. Purpose The Enterprise Authorization Design Blueprint establishes a standardized enterprise authorization framework to support the implementation and long-term operation of SAP S/4HANA and other enterprise applications. The blueprint provides a common design approach for Business Roles, Functional Roles, Technical Roles and User IDs, ensuring that business responsibilities are translated into application authorization in a consistent, controlled and auditable manner. Rather than assigning application access directly to users, the Enterprise Authorization Design introduces a layered authorization architecture that separates business responsibilities from technical implementation. This separation improves governance, promotes reuse of authorization components, simplifies maintenance and supports future organizational changes without extensive redesign. The blueprint serves as the primary design reference for project implementation, operational support, role maintenance and future enhancement activities. Enterprise Authorization Vision To establish a standardized, business-driven and governable authorization framework that delivers secure, reusable and maintainable access management across enterprise applications while supporting business agility and regulatory compliance. Enterprise Authorization Design Objectives The Enterprise Authorization Design has been developed to achieve the following strategic objectives. Business Benefits Consistent authorization design across business domains. Reduced duplication of authorization roles. Improved governance and accountability. Simplified onboarding, transfer and offboarding. Better audit readiness and traceability. Improved maintainability for long-term operations. Enterprise Authorization Overview Enterprise Authorization is based on a layered authorization model. Each layer has a specific responsibility and interacts only with adjacent layers, enabling clear separation between business responsibilities and technical implementation. Enterprise Authorization Model Business Position ↓ Business Role ↓ Functional Role ↓ Technical Role ↓ Application User ↓ Enterprise Application Enterprise Authorization Architecture The Enterprise Authorization Architecture establishes a layered authorization model that separates business responsibilities from technical implementation. Each authorization layer has a clearly defined responsibility and interacts only with adjacent layers to simplify maintenance, improve governance, and maximize role reuse. Architecture Overview Enterprise Authorization ↓ Business Role ↓ Functional Role ↓ Technical Role ↓ Application User Architectural Principles Business responsibilities shall remain independent from application authorization. Functional Roles shall maximize reuse across multiple Business Roles. Technical Roles shall implement only one business function. Authorization shall follow the principle of Least Privilege. Every authorization component shall have accountable ownership. Authorization changes shall be traceable and auditable. Layer Interaction Business Roles aggregate Functional Roles. Functional Roles map one or more Technical Roles. Technical Roles implement application-specific permissions and are assigned to Application Users through the approved authorization assignment model. Enterprise Authorization Guiding Principles The following guiding principles shall govern all authorization design, implementation, and maintenance activities. Design Philosophy The Enterprise Authorization Design emphasizes standardization, simplicity, reusability, and governance. New roles should only be created after evaluating existing authorization components. Business-driven design takes precedence over technical convenience. Role Cardinality Enterprise Authorization Scope This blueprint defines the enterprise standards governing authorization design, ownership, assignment, governance and lifecycle management. Design Assumptions The Enterprise Authorization Design is based on the following assumptions. Business Position → Business Role → Functional Role → Technical Role → Application User is the standard authorization hierarchy. Business Roles represent responsibilities rather than individual users. Technical Roles are implemented as SAP PFCG Single Roles. Role naming follows the Enterprise Role Naming Convention workbook. Every authorization component has an assigned business owner. Authorization changes follow the enterprise governance process. Design Constraints The following constraints shall be considered during authorization design and implementation. Success Criteria The Enterprise Authorization Design shall be considered successful when the following outcomes are achieved. Business Roles consistently represent approved business responsibilities. Functional Roles are reused wherever appropriate. Technical Roles implement a single business function. Application Users receive authorization through the approved assignment model. Role ownership and approval responsibilities are clearly defined. Authorization lifecycle activities are documented and auditable. Enterprise authorization standards are consistently applied. Authorization Design Strategy This chapter establishes the enterprise authorization design strategy adopted by the S/4HANA Transformation Project. It defines the principles, architecture, authorization layers, assignment strategy, design decisions and governance standards used to build a scalable, reusable and maintainable authorization model. Design Strategy Overview Purpose The Enterprise Authorization Design Strategy provides a standardized approach for designing authorization structures that align business responsibilities with application authorization while maintaining governance, scalability and operational efficiency. Strategy Objectives Authorization Design Philosophy Enterprise Authorization Architecture Business Position → Business Role → Functional Role → Technical Role → Application User Authorization Layer Relationship Authorization Assignment Strategy Users shall receive Business Roles through approved workflow. Business Roles contain Functional Roles. Functional Roles contain Technical Roles. Technical Roles implement application authorization. Direct Technical Role assignment should be avoided. Authorization Design Decision Matrix Enterprise Authorization Design Standards ADS-001 Authorization shall be business driven. ADS-002 Business Roles shall represent business responsibilities. ADS-003 Functional Roles shall be reusable. ADS-004 Technical Roles shall implement one business function. ADS-005 Least Privilege shall be applied. ADS-006 Naming shall comply with the Enterprise Naming Convention Standard. Enterprise Authorization Design Rules ADR-001 Business Roles shall represent business responsibilities. ADR-002 Functional Roles shall be reusable across multiple Business Roles. ADR-003 Technical Roles shall implement a single business function. ADR-004 Composite Roles shall only be used for administrative grouping. ADR-005 Business Roles shall not contain authorization objects. ADR-006 Functional Roles shall not be assigned directly to users. ADR-007 Technical Roles shall follow the Enterprise Naming Convention. ADR-008 Direct Technical Role assignment should be avoided. ADR-009 Existing roles shall be evaluated before creating new roles. ADR-010 Authorization shall follow Least Privilege. ADR-011 Every Business Role shall have a designated Role Owner. ADR-012 Every Functional Role shall have a Functional Owner. ADR-013 Every Technical Role shall have a Technical Owner. ADR-014 Role ownership shall be documented. ADR-015 Authorization shall follow approved workflow. ADR-016 Role changes shall be documented. ADR-017 Periodic role review shall be performed. ADR-018 Exceptions shall follow governance procedures. ADR-019 Authorization activities shall be auditable. ADR-020 Duplicate authorization components shall be avoided. Authorization Design Checklist Authorization Design Anti-Patterns Authorization Naming Strategy The Enterprise Authorization Naming Strategy establishes a standardized naming approach for all authorization components within the Enterprise Authorization Model. The strategy ensures authorization artifacts are consistently named, uniquely identified, and easily understood across all enterprise applications. Detailed naming syntax is maintained in the Enterprise Role Naming Convention Workbook. A consistent naming strategy enables business and technical stakeholders to identify the purpose, ownership, and intended use of authorization components while improving governance, maintainability, reporting consistency, and auditability. Naming Objectives Naming Principles Naming Governance Authorization Naming Scope Naming Hierarchy Business Role ↓ Functional Role ↓ Technical Role ↓ Application User ID Naming Ownership Naming Standards Reference This blueprint defines naming governance and strategic principles. Detailed naming syntax, abbreviations, prefixes, suffixes, validation rules and examples are maintained in the Enterprise Role Naming Convention Workbook, which serves as the single source of truth. Naming Lifecycle Create → Review → Approval → Implementation → Maintenance → Retirement Naming Design Rules BUSINESS ROLE DESIGN Purpose Business Roles represent the highest business-facing authorization layer within the Enterprise Authorization Model. Unlike Technical Roles, which define application-specific permissions, Business Roles represent approved business responsibilities performed by users within the organization. A Business Role defines what a user is responsible for performing rather than how application authorization is technically implemented. Business Roles act as the logical authorization layer between organizational responsibilities and reusable authorization components. Rather than containing authorization objects or application transactions directly, Business Roles aggregate one or more Functional Roles required to perform a defined business responsibility. This layered authorization model separates business authorization from technical implementation, allowing organizations to simplify authorization administration while improving governance, standardization, and long-term maintainability. Business Roles are intended to remain relatively stable despite organizational restructuring, application upgrades, or changes to Technical Roles. Changes to technical authorization should generally be absorbed within Functional Roles and Technical Roles without affecting the Business Role structure. Purpose Statement Represent approved business responsibilities using a consistent authorization model. Standardize Business Role design across the enterprise. Promote reuse of Functional Roles. Separate business authorization from technical authorization. Simplify authorization assignment and maintenance. Support organizational changes without redesigning technical authorization. Strengthen governance, accountability, and auditability. Design Objectives Scope Governs the design, implementation, maintenance, and governance of Business Roles within the Enterprise Authorization Model. Business Role Architecture Business Role Components Business Role Naming Convention Business Role Design Principles Business Role Assignment Strategy Business Role Ownership Business Role Lifecycle Business Role Design Rules Business Role Governance The implementation details for Functional Roles, Technical Roles, and User IDs are described in subsequent chapters. Business Value Guiding Principles Business Roles shall represent approved business responsibilities. Business Roles shall contain Functional Roles only. Business Roles shall not contain SAP authorization objects. Business Roles shall not contain SAP transactions. Business Roles shall remain understandable by business users. Business Roles shall follow the Enterprise Role Naming Convention. Business Roles shall support the principle of Least Privilege. Every Business Role shall have a designated Business Role Owner. Business Roles shall undergo periodic review. Business Roles shall remain governed throughout their lifecycle. Business Role Concept Definition A Business Role is the highest business-facing authorization component within the Enterprise Authorization Model. It represents an approved business responsibility, job function, or organizational responsibility that is performed by one or more users. Business Roles are designed from a business perspective and serve as the primary authorization entity assigned to users. They provide a stable abstraction layer between business responsibilities and the underlying technical authorization implementation. Rather than containing application-specific authorizations directly, a Business Role aggregates one or more Functional Roles required to perform a defined business responsibility. This layered approach enables business responsibilities to remain independent of application-specific authorization structures while promoting governance, maintainability, and scalability. A Business Role shall not contain SAP authorization objects, authorization fields, transaction codes, or application-specific permissions. Such technical authorizations are managed through Technical Roles as described in subsequent chapters. Business Responsibility Business Roles shall be designed based on business responsibilities, not organizational titles or individual users. A business responsibility represents a set of related activities that a user performs as part of an approved business process. Users performing the same responsibility should be assigned the same Business Role regardless of their department, legal entity, or reporting structure, unless organizational differentiation is explicitly required. Characteristics Business Role vs. Technical Role 3.2.5 Key Principles Represent a clearly defined business responsibility. Remain understandable by business stakeholders. Aggregate Functional Roles only. Be independent of application-specific authorization. Support the principle of Least Privilege. Follow the Enterprise Role Naming Convention. Have clearly defined ownership and governance. Be subject to periodic review and continuous improvement. Business Role Architecture Architecture Overview Business Roles form the business layer of the Enterprise Authorization Model and establish the relationship between organizational responsibilities and reusable authorization components. Design Philosophy The Business Role architecture is based on the principle of separation of responsibilities. Business Roles define who performs a business responsibility, Functional Roles define what business capabilities are required, and Technical Roles define how application authorization is implemented. This separation minimizes the impact of organizational or technical changes and promotes reuse of authorization components across the enterprise. Architecture Principles Relationship Model Business Role Components Each Business Role shall contain a minimum set of standardized information to support governance, lifecycle management, reporting, and audit activities Mandatory information shall be maintained within the enterprise authorization repository. Mandatory Components Mandatory Metadata The following metadata shall be maintained for every Business Role: Creation Date Created By Last Modified Date Last Modified By Business Unit Country Company Code, where applicable Approval Status Lifecycle Status Review Date Documentation Reference Maintaining complete metadata supports governance, traceability, and regulatory compliance. Business Role Naming Convention The Business Role Naming Convention establishes a standardized approach for naming Business Roles within the Enterprise Authorization Model. A consistent naming convention ensures that Business Roles are uniquely identified, easily understood by business users, and consistently managed across the enterprise while supporting governance, reporting, maintenance, and audit activities. This section defines the naming principles applicable to Business Roles. Detailed naming syntax, abbreviations, identifiers, validation rules, and code definitions are maintained within the Enterprise Role Naming Convention Workbook, which serves as the single source of truth. Naming Objectives 3.5.3 Naming Philosophy Business Role names shall: Represent approved business responsibilities. Be understandable by business stakeholders. Remain independent of SAP technical terminology. Follow a consistent enterprise naming structure. Avoid ambiguous abbreviations. Remain stable throughout the Business Role lifecycle. Naming Structure Business Role names shall comply with the Enterprise Role Naming Convention. The naming convention defines standardized components such as role prefix, business function, business responsibility, organizational context, country identifier, and optional differentiators. Detailed syntax and coding standards are maintained within the Enterprise Role Naming Convention Workbook and shall not be duplicated within this blueprint. Business Role Design Principles Business Roles shall be designed using a consistent set of enterprise design principles to ensure that authorization remains aligned with business responsibilities while supporting governance, maintainability, scalability, and regulatory compliance. These principles provide the foundation for designing Business Roles that are reusable, understandable by business stakeholders, and independent from application-specific authorization implementation. All Business Roles shall comply with the design principles defined in this section. Business-Driven Design Business Roles shall be designed based on approved business responsibilities rather than organizational structures, departments, or individual user requirements. The objective is to ensure that Business Roles remain stable despite organizational restructuring or personnel changes. Business Roles shall represent what business activities a user is authorized to perform, rather than which SAP transactions or authorization objects are assigned. Business requirements shall always take precedence over technical implementation when designing Business Roles. Responsibility-Based Design Each Business Role shall represent a clearly defined business responsibility. Business Roles shall not combine multiple unrelated responsibilities solely to reduce the number of roles within the system. Where multiple independent responsibilities exist, separate Business Roles shall be created and assigned according to approved business requirements. This approach promotes authorization transparency, simplifies periodic access review, and supports effective Segregation of Duties (SoD) analysis. Reusability Business Roles shall maximize the reuse of existing Functional Roles whenever practical. Before creating a new Business Role, existing Business Roles and Functional Roles shall be evaluated. Duplicate Business Roles shall be avoided unless justified. Designing reusable authorization components reduces maintenance effort, improves consistency, and minimizes authorization complexity. Least Privilege Business Roles shall only include the minimum Functional Roles required to perform the approved business responsibilities. Authorization shall not be granted based on convenience or anticipated future requirements. Additional access shall require separate business justification and approval. Business Roles shall support the Principle of Least Privilege. Standardization Business Roles shall comply with all enterprise authorization standards, including the Enterprise Authorization Design Blueprint, Enterprise Role Naming Convention Workbook, Authorization Governance Standard, User Management Approval Matrix, and Segregation of Duties Standard. Governance Every Business Role shall have a Business Role Owner, Control Owner, Business Description, Functional Role Mapping, Naming Standard Compliance, and Lifecycle Status. Business Roles shall be subject to periodic review to verify continued business relevance, ownership, and compliance. Design Considerations Business Role Assignment Strategy Business Role assignment shall be based on approved business responsibilities and shall follow the enterprise authorization governance process. Assignments shall not be performed based on individual preferences, convenience, or historical user access. Business Role assignment shall support authorization consistency, governance, and regulatory compliance across the enterprise. Assignment Principles Assignment Model Business Position → Business Role → Application User Business Roles shall be assigned to users through the approved identity and access management process. Direct assignment of Technical Roles to users should be avoided except where explicitly approved by SAP Security and documented according to enterprise governance requirements. Assignment Rules Assignment Validation Business justification confirmed. Business approval obtained. Existing Business Role evaluated. SoD conflict assessment completed. Least Privilege validated. Naming compliance confirmed. Documentation completed. Business Role Ownership Effective ownership is fundamental to maintaining a secure, governed, and sustainable authorization environment. Every Business Role shall have clearly defined ownership throughout its lifecycle to ensure accountability for design, approval, maintenance, periodic review, and retirement. Business Role ownership establishes clear responsibilities between business stakeholders and SAP Security, ensuring that authorization decisions remain business-driven while technical implementation remains under the control of SAP Security. Ownership shall be formally assigned, documented, and maintained throughout the lifecycle of every Business Role. Ownership Principles Ownership Model Ownership Responsibilities Business Role Owner Approve the creation of new Business Roles. Approve modifications to existing Business Roles. Validate business requirements. Ensure Business Roles remain aligned with business processes. Review Business Roles periodically. Initiate retirement of obsolete Business Roles. Control Owner Conduct periodic Business Role certification. Validate ongoing business necessity. Review compliance with enterprise authorization standards. Escalate ownership or compliance issues. SAP Security Configure supporting Functional Roles and Technical Roles. Ensure implementation complies with enterprise authorization standards. Maintain technical documentation. Support periodic authorization reviews. RACI Matrix Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed. Business Role Lifecycle Business Roles shall be managed through a controlled lifecycle to ensure authorization remains accurate, relevant, secure, and aligned with approved business responsibilities. Lifecycle management provides governance from the initial business request through retirement while ensuring complete traceability, accountability, and auditability. Every Business Role shall follow the lifecycle defined in this section. Lifecycle Stages Business Request Business Analysis Business Role Design Review Approval Implementation Assignment Periodic Review Modification Retirement Lifecycle Description Lifecycle Controls Business justification shall exist before a Business Role is created. Formal approval shall be obtained before implementation. All lifecycle activities shall be documented. Version history shall be maintained. Business Roles shall undergo periodic certification. Retired Business Roles shall not be assigned to users. Lifecycle Principles Governance Traceability Accountability Compliance Auditability Continuous Improvement Business Role Design Rules Design Rule Compliance Exceptions shall be supported by documented business justification. Exceptions shall be formally approved. Exceptions shall be recorded in the authorization repository. Exceptions shall be reviewed periodically. Business Role Design Checklist Prior to the creation, implementation, or modification of a Business Role, a structured design validation shall be performed to ensure compliance with enterprise authorization standards. Completion of this checklist is mandatory for all newly created Business Roles and significant Business Role modifications. Design Validation Checklist Implementation Readiness Checklist Periodic Review Checklist Business responsibility remains valid. Business Role Owner remains assigned. Control Owner remains assigned. Functional Role mapping remains appropriate. Naming Convention remains compliant. No duplicate Business Role exists. Business Role is still actively used. Retirement is not required. Business Role Anti-Patterns Business Role Anti-Patterns identify common design mistakes that reduce authorization quality, increase maintenance effort, and weaken governance. Common Anti-Patterns Anti-Pattern Detection Large numbers of duplicate Business Roles. Frequent emergency access requests. High number of Business Role modifications. Business Roles with unclear ownership. Business Roles assigned to very few users. Significant overlap between Business Roles. Business Role Examples The following examples illustrate how Business Roles aggregate Functional Roles while remaining independent from application-specific authorization implementation. Example Business Role Mapping Relationship Example Business Position -> Business Role -> Functional Roles Assignment Example