Authorization Concept for S/4HANA Cloud

March 26, 2018

1 Content

1 Content ............................................................................................................................ 2

2 Authorization Concept for S/4HANA Cloud ................................................................. 3

2.1 Introduction ................................................................................................................................................. 3
2.1.1 Purpose and scope .................................................................................................................................. 3
2.1.2 Cloud deployment .................................................................................................................................... 3

2.2 Solution approach....................................................................................................................................... 3

2.2.1 Overview on approach and phases .......................................................................................................... 3
If you want to define additional read-/write permissions or permissions on instance level, for example,
cost center or sales organization, define restrictions within the business roles. ...................................... 4
2.2.2 Relevant entities and their relation (meta-model) .................................................................................... 4
2.2.2.1 Business role ......................................................................................................................................... 5
2.2.2.2 Business Catalog .................................................................................................................................. 6
2.2.2.2.1 Design Considerations ...................................................................................................................... 6
2.2.2.3 Authorizations ........................................................................................................................................ 7
2.2.2.4 Restriction types .................................................................................................................................... 8
2.2.2.4.1 Restricting the activities .................................................................................................................... 8
2.2.2.4.2 Mapping Restriction Types to Authorization Objects ........................................................................ 8
2.2.2.5 Fields ..................................................................................................................................................... 9
2.2.2.6 Restrictions ............................................................................................................................................ 9

2.3 From Design Time to Run Time ................................................................................................................. 9

3 Appendix ....................................................................................................................... 11
3.1 Creating and assigning a user role .........................................................................................................11

customer Page 2
2 Authorization Concept for S/4HANA Cloud
2.1 Introduction
2.1.1 Purpose and scope

This document presents the authorization concept for S/4 HANA cloud, enabling the customer key
users to maintain the authorizations for business users in a simplified and transparent way.

2.1.2 Cloud deployment

SAP delivers ready to use content and specialized Fiori key user tools to allow customizations. SAP
is responsible for the lifecycle. S/4HANA cloud authorization concept implements an additional
layer on top of the ABAP authorization concept and heavily relies on high-quality content
delivered by SAP.

In the UI the access is done only via Fiori Launchpad with SAML-based single sign-on, the
authorization assignment is made via IAM key user Fiori UIs, based on IAM business catalogs and
there are pre-delivered role and authorization content for business catalogs.

In Integration the access is made via HTTP with basic authentication or certificates and
authorizations are assigned via IAM key user Fiori UIs, based on communication scenarios with pre-
delivered role and authorization content for communication scenarios.

2.2 Solution approach

2.2.1 Overview on approach and phases

1. The key user assigns a set of functionality (i.e. apps bundled in catalogs) to a business role.
2. The key user optionally defines responsibilities as restrictions on business object instances.
3. The key user assigns the business roles including restrictions to users.

Based on these definitions the necessary authorizations are generated in the backend; the key user
does not deal with authorization objects: authorized values are calculated on the database and data
is filtered there based on the defined restrictions.

A new design time for the definition of business roles hides much of the PFCG complexity and it
works as follows:

1. Business functionalities (Fiori apps, reports and KPIs based on CDS views, Web Dynpro
apps, in rare cases HTML GUI apps) are divided into semantically meaningful business
catalogs, representing tasks or sub-processes within a business process. These catalogs are
the most fine-grained unit regarding structuring of work and authorization assignment and
typically limited to an application area.

customer Page 3
 2. For each catalog there are already provided, prepared and prefilled, the authorizations
required for the apps in the catalog. The link from catalog to authorizations is currently
established with the Fiori-PFCG integration.
3. For each catalog, it is defined the restriction type, a set of fields for authorization
restriction exposed to the customer admin. These fields map to authorization fields which
are not prefilled by SAP.
4. The administrator defines business roles via a new Web UI by combining catalogs and
values for the restriction definition. Such business roles represent a kind of "workcenter"
covering a certain business process and responsibility area. Technically, PFCG roles are
generated based on the predefined authorization data and the definitions by the customer
key user.

Business role templates group several business catalogs for a defined business purpose. There is a
coarse granular cut per job or persona performing a given set of business tasks. Check if the
predefined business role templates correspond to your business requirements:

• If yes, then use them to define your business roles.

• If not, combine business catalogs into a custom business role.

2.2.2 If you want to define additional read-/write permissions or permissions on instance level,
for example, cost center or sales organization, define restrictions within the business
roles.Relevant entities and their relation (meta-model)

Users will be granted access to (subsets of) functionality through assignment of authorizations in
terms of business roles. Further limitations of the permissions, for example on instance level, will
be governed by restrictions. Restrictions provide a convenient way for customers'
administrators to define a finer granular access to the according resources.

The meta-model provides the overall framework for modelling authorizations and is the basis of
the authorization models.

A more simplified picture:

customer Page 4
The semantics of the main entities and relations are described in the following:

2.2.2.1 Business role

The central entity for user authorization is the business role. A business role, which comprises
several catalogs is assigned to business users.

The business role is not primarily an authorization artifact but a grouping of business functionality
for a certain business user in a certain role. UI and authorizaitons go hand-in-hand. SAP will
deliver the system with predefined roles, so that the customer can start using the system right
away, and adopting it if needed.

A business role consists of catalogs and restrictions. Since several catalogs may be associated to a
restriction type, the catalogs can be categorized by their restriction types. For each restriction type
a set of restriction instances will be defined.

Restriction instances restrict the access to the data instances for each catalog belonging to this
restriction type. Several restriction instances of the same restriction type enhance accessibility
by boolean OR combination of the entire restriction instances (but not on particular values of
restriction fields!)

All (atomic) restriction types of a business role can be combined into an overall restriction type for
the business role by merging all fields of the atomic restrictions into fields of the overall restriction
type. Fields of two atomic restriction types with the same name end up in one field with this name
in the overall restriction type. The atomic restriction types of the underlying catalogs are projections
from the merged overall restriction type. Due to the ontological uniqueness of the field names, no
conflicts with naming, semantics, domain and scope do occur during the merge process.

Observe that the combination of the atomic restriction types into an overall restriction type only
makes sense if the restriction instances of the atomic restrictions can be derived from the merged
restrictions by projection. This symmetry between the set of atomic restrictions and overall

customer Page 5
restriction breaks if some of the atomic restriction instances require other vaules than provided by
the overall restriction instances.

2.2.2.2 Business Catalog

A business catalog constitutes a self-contained unit from an application domain point of view. A
business catalog bundles:

1) a set of functionality in terms of (Fiori) applications, reports, KPIs, etc. Reports are of
analytical nature, like a Design Studio report or some other analytical report variant. KPI
provides a measured entity and is associated with a threshold for this entity. (Fiori)
applications, reports or KPIs each have a set of system entry points.
2) a set of authorizations associated to each application, report, KPI.
3) a set of restrictions which further adjust and confine the authorizations; the restrictions
are defined as restriction fields of a certain restriction type; one restriction type is
associated to a catalog and several catalogs may be associated to a restriction type.

Business catalogs are the central object for UI and authorization assignment to business users and
for structuring and organizing the menu and authorization maintenance.

• The Business Catalog (Fiori) is the visual part of a business catalog and is represented as a
Fiori catalog.
• The Business Catalog (IAM) is the additional cloud-specific object that complements the
Fiori catalog in the S/4HANA cloud with business catalog roles and restrictions to achieve
automated lifecycle management for authorizations and extensibility.

If a user is assigned to a business catalog, he/she gets access to all apps included in the catalog and
therefore requires the corresponding authorizations.

In the cloud, business catalogs are defined by SAP and authorizations are delivered out-of-the-box
with the corresponding business catalog roles. The customer key user bundles business catalogs in
business roles and defines the instance-based authorizations via restrictions, however can not
change the composition of the catalog. The right cut of business catalogs is therefore of outmost
importance.

2.2.2.2.1 Design Considerations

Business catalog design has to follow these principles:

• Business catalogs are composed for a certain business context.

• Business catalogs divide the S/4HANA business functionality into semantically meaningful
"building blocks" that represent tasks or sub-processes for a certain business user within the
overall business process.
• Business catalogs are composed of one or more apps. This may be Fiori apps, HTMLGUI
transactions or Web Dynpro applications. One app might be assigned to one or several
business catalogs, but the latter is the exception and normally only applies to generic apps.
• Business catalogs are composed in a way that they are Segregation-of-Duty (SoD) compliant.
This means they are typically small.

customer Page 6
 • Business catalogs are not to be too fine-grained. We need a predefined aggregration of
apps to provide a consumable set of building blocks, from which the customer composes the
business roles. This is particularly important for S/4HANA cloud, where we target more
standardization.
• Business catalogs for read-access to factsheets, object pages or display-only transactions are
normally provided as separate catalogs. For factsheets and object mapping, only target
mappings are added (i.e. they have no visible tiles) because they can only be started with
parameters. For display-only transansactions, also visible tiles are added.

• Business catalogs, i.e. those delivered in S/4HANA cloud, need to be considered like
published APIs. Incompatible changes are to be kept to a minimum, however sometimes
they can't be avoided.

In the S/4HANA cloud editions, the complete handling of roles, role content and role lifecycle is
controlled by SAP. Business catalogs for S/4HANA cloud include the Fiori catalog combining the
relevant apps as well as additional metadata to:

1) activate only those catalogs part of the S/4HANA cloud editon and in the scope of the
customers business configuration.
2) automate all steps required to assign business catalogs to business users.
3) create the required authorization roles.
4) restrict the authorization roles to the activities and data the customer wants, and generate the
required authorization profiles.

In S/4HANA cloud editions, the customer's IAM key user assigns UIs and authorizations to users by
bundling business catalogs into business roles and assigning those to users.

The business catalog documentation includes the following parts:

1) Functional description of the catalog, potentially including the area / scope / business
processes the business catalog is assigned to.
2) Criteria for restricting the catalog to organize responsibilities. Usually this means mentioning
the restriction types such as plant or sales area assigned to the business catalog, assuming that
the restriction types are self-explanatory.
3) Related business catalogs. As an example, for a business catalog that enables creating an
order, you would mention the master data catalogs to display customers and products and the
business catalog that enables approval of the orders.

2.2.2.3 Authorizations

Authorizations describe which functionality and data can be accessed by the business user. There
are two types of authorizations.

1) Start authorizations to launch functionality

2) Instance based authorizations constraining access on a data object on instance level.
Instance-based authorizations are role and user specific

customer Page 7
Authorizations will be further adjusted and confined through restrictions defined at the catalogs.
In the authorization concept of ABAP the authorizations are realized by the PFCG authorization
objects of a business role or user.

2.2.2.4 Restriction types

Restriction types map to authorizations. The mapping is determined by the restriction type and
the authorization entities of the catalog. They have a given data structure in terms of restriction
fields, may be reused in different catalogs and have a well-defined semantics and are independent
of the assigned catalogs.

The restriction type is a set of restriction fields, which are "business fields" selected from the global
field name catalog (typical examples cost center, sales organization, ...).

One restriction type is defined by development for each catalog: the same restriction type can be
used for catalogs of a certain application area, in case reuse of restrictions and thus authorization
object values is desired. Different restriction types can be used for catalogs of a certain application
area, in case different restriction fields or different mappings of restriction fields to authorization
fields are relevant.

Combining catalogs to a business role leads to a combined restriction type of the role.
When defining business roles, the customer key user defines (instances of) values for the role's
restriction types. At the time of role generation, these values feed the prepared authorization data
for the catalog and sum up in a completely specified business role that is then assigned to users (one
business role instance per value set).

2.2.2.4.1 Restricting the activities

Various use cases require restriction of the user's activities beyond the functional scope defined
via the apps, especially regarding read only vs. read write access. For example:

• An auditor shall be able to see everything, but must not change anything --> This requires a
read-only mode.
• A sales clerk shall be able to see orders of all sales units, but only change orders of his own
unit --> read-only mode for some instances, read-write for others.
• A manager shall be able to approve orders for his cost center, but not his own orders -->
"Approve" activity for some instances, but not for others.

At the definition of restriction values for a business role, a read-only indicator can be set per
restriction instance, the assignment of the app with a certain OData service as system entry point
provides the functional authorization for this service.

2.2.2.4.2 Mapping Restriction Types to Authorization Objects

Restriction type maps to authorization objects by mapping one or several fields of the restriction
type to fields of authorization objects. This mapping has to be explicitly defined. The mapping is
defined "globally" between restriction type and authorization objects, it is not defined under the
context of a catalog.

customer Page 8
The user can define several instances (value sets) per restriction type and assign those to business
roles: at role generation time, this sums up to several values for the authorization object, which is
then assigned to the user. Comparable to the OR-relation that exists today, in case authorization
objects are included in several roles assigned to a user.

2.2.2.5 Fields

The semantics, domain and scope are manifested in the fields, the fields are part of a global
(extended) field catalog, defining the field name, domain description and scope.

Binding semantics, domain and scope to a unique field name elevates field names to a sort of
ontological entities. Thereby the catalogs for field names and restriction types effectively become
the source of truth, they will be instantiated by assigning values to the fields. The values of the
fields in a restriction instance will be assigned explicitly or by evaluating dedicated rules at
runtime; the rules are associated to the restriction type on model level.

2.2.2.6 Restrictions

Restrictions modify the access permissions supplied by the according authorizations. Several
restriction instances of the same type can be created per catalog in a business role. This leads to
extended access behavior; for example the access permission expressed in terms of PFCG
authorizations will be computed by logical or-combination of the restriction instances.

If you define business roles with restrictions, you should review these restricted roles after an
upgrade. Check whether new restriction fields have been added during the upgrade and whether
the settings for them are correct or require adjustments. Keep in mind that empty restriction
fields mean that no access to the underlying data is granted.

You must define the same business roles and the corresponding restrictions in the quality and
production system. After an upgrade of the quality system you should test if everything is still
working and especially review restrictions. In case of adjustments, they have to be done the same
also in the productive system.

2.3 From Design Time to Run Time

Standard and custom apps will provide authorization entities/objects, catalogs and restriction
types as well as mappings between restriction fields/rules and according authorization entities.

customer Page 9
At configuration and customizing time admin user will adapt, create and assign business roles to
users. Adaptation essentially comprises configuration and customization of restrictions and rules.

After configuration and customization, the business role instances with the according restriction
instances and rules will be generated. Due to performance reasons it might be conceivable that
some rules will be materialized into derived user and application contexts associated to the
business roles. These context data may be represented as rule tables associated to business role
and user ID.

customer Page 10
3 Appendix
3.1 Creating and assigning a user role

This chapter is a guide on how to create and assign custom roles in SAP S/4 HANA.

Refer to the user onboarding guide for SAP S/4HANA Cloud and the product documentation.

customer Page 11
customer Page 12