assignment service authorization objects sap

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SUSH Assignment: Service --> Authorization Objects #1582

larshp commented Jul 7, 2018

larshp commented Oct 7, 2019

Sorry, something went wrong.

ThomasPloski commented Aug 11, 2020 • edited Loading

• 👍 1 reaction

larshp commented Jan 11, 2021

No branches or pull requests

• Access Risk Analysis
• Compliant Provisioning
• Access Certification
• Elevated Access Management
• Role Management
• Risk Quantification and Transaction Monitoring
• Configuration Change Monitoring
• Business Process Control Management
• Manual Process Control Management
• Dynamic Data Masking
• Vulnerability Scanning
• Threat Detection
• Transport Control
• Session Logging and DLP
• ERP and Cloud Migrations
• Audit Readiness
• Finance Transformation
• Cross Application SOD
• Continuous Compliance
• SAP Data Security
• Mergers and Acquisitions Integration
• Modernize IGA
• User Access Reviews
• Application Owner
• Internal Audit
• Finance Leaders
• CISO and IT Security
• Oracle Fusion Cloud
• PeopleSoft Campus Solutions
• SAP SuccessFactors
• Microsoft Dynamics 365
• SAP Access Control
• Microsoft Entra ID Governance
• Data Security Regulations
• Financial Regulations

• Innovation Series

Configuring and Assigning SAP Authorizations in SAP Fiori Apps

SAP has been implementing a strategy for how users interact with its software for several years. Complex SAP applications are divided into role-based SAP Fiori apps to improve user-friendliness and enhance the user experience. Many companies are considering implementing these apps and must determine which authorizations their employees require to access them.

In the following article, we will distinguish between front-end and back-end authorizations. This distinction is relevant for you only if you choose a central hub deployment approach. If you instead take the path of embedded deployment, you do not need to differentiate between front-end and back-end authorizations; you can include all the authorizations in one role.

Protect Critical SAP Transactions & Address Business Risks

Learn how Pathlock protects SAP transactions with sophisticated controls that strengthen access policies and enhance logging & analytics capabilities.

Basic Authorizations for Access to the SAP Fiori Launchpad

The SAP Fiori launchpad is the central point of access for all Fiori apps. The following authorizations must be assigned to a user to allow access to the launchpad:

Front-end Authorizations:

• Transaction /UI2/FLP: This transaction allows the launchpad to be called directly from the SAP GUI.
• The S_SERVICE authorization object must be configured as follows for the SAP Fiori launchpad OData services:

Integrating both the IWSV and the IWSG services via the Role menu is important. To do this, you need to select the authorization default TADIR service, the R3TR program ID, and the corresponding IWSV or IWSG service.

• The authorization object /UI2/CHIP is required for transaction /UI2/FLP as well as for some of the services listed above. This is why it is automatically included in the role with the following parameters:

The SAP standard roles SAP_UI2_USER_700 and SAP_UI2_USER_750 are considered predefined SAP Fiori roles for users and are templates that can be copied. However, they include only the IWSV entries, meaning they are incomplete, and you must add the IWSG entries listed above.

Back-end Authorizations:

• The authorization objects S_RFC and S_RFCACL are required to enable access to the back-end server via a trusted RFC connection.

App-Specific Authorizations for Access to Individual Fiori Apps

App-specific authorizations are required to access individual Fiori apps from the SAP Fiori launchpad. The relevant authorizations for all available SAP Fiori apps are listed in the Fiori Apps Reference Library.

How the front end is shown depends on the assigned Fiori catalogs and groups. The groups and catalogs necessary for access to the relevant app are entered in the configuration settings of the Fiori Reference Apps Library.

Fiori catalogs are a collection of apps that logically belong together and contain definitions of the tiles (e.g., title and symbol) and target assignment. For example:

Fiori groups represent collections of apps that logically belong together; these collections define the initial Fiori launchpad screen. The apps in a group can originate with multiple catalogs. Users see only those apps on their respective launchpad for which they are authorized based on their group and catalog assignment.

The SAP Fiori tile catalogs and groups are integrated via the Role menu. The integration of the catalog adds to the role of the IWSG services required to start the Fiori app and the IWSV services required to call business data (S_SERVICE authorization object). If these services have SU24 authorization default values, then these are also part of the authorization role.

Integration of Fiori Groups and Catalogs in the App-specific Authorizations

The following is a summary of how the app-specific authorizations fit together:

• Integration of the required Fiori groups via the Role menu.
• Integration of the required Fiori catalogs via the Role menu.

This ensures that the IWSG services required to start the Fiori app are included automatically in the role (S_SERVICE authorization object).

This ensures that the IWSV services required to call business data are included automatically in the role (S_SERVICE authorization object). Additional authorizations for business transactions are also included, for example, authorization default values from SU24.

The recommendation is to use the technical SAP catalogs and groups as a reference by saving them in the customer-specific namespace and then streamlining them as much as possible (for performance reasons).

Before you implement app-specific authorizations, ensure that your SAP system’s front-end and back-end components have the required status and that the relevant SAPUI5 applications and OData services are activated.

If you need support to set up SAP Fiori authorizations, get in touch with us today.

SAP published 17 new and eight updated Security Notes for A...

SAP published 16 new and two updated Security Notes for Jul...

SAP published 10 new and two updated Security Notes for Jun...

In July 2023, the U.S. Securities and Exchange Co...

Explaining Analysis Authorizations

After completing this lesson, you will be able to explain analysis authorizations .

Business Example

This lesson covers how to implement the analysis authorizations, and details about how analysis authorizations work.

Analysis Authorizations Basics

Before delving further into details, let's briefly summarize what you have learned about Analysis Authorizations thus far:

The customer, not SAP, decides which data is relevant for the authorization checks by flagging the corresponding Characteristics and Navigation Attributes as Authorization-Relevant .

With the transaction RSECADMIN , you create Analysis Authorizations consisting of a group of authorization-relevant characteristics and navigation attributes and assign the authorized values.

Analysis Authorizations can be assigned to the users:

• Directly with the user assignment in transaction RSECADMIN
• Indirectly by using the authorization object, S_RS_AUTH and assigning it to a profile and then the profile to a role
• The Analysis Authorization 0BI_ALL consisting of all characteristics and navigation attributes flagged as authorization relevant and authorized for all values ( * ) grants access to all authorization-relevant data.

Restricted Access to Levels of Data

With analysis authorizations, you can restrict access to data at any of the following levels and combinations of them:

• InfoProvider
• Characteristics and Characteristic Values
• Characteristic's Hierarchies and Hierarchy Node Values
• Key Figures

Also, access to data can be restricted to the type of activity and to specific time periods.

The following two tables show examples of those restrictions:

Restricted Access Concerning Activity and Time Period

While restricting users to the data of a certain InfoProvider can be an easy way to set up and maintain analysis authorizations, this severely restricts access. This action means that users can access either all the data in an InfoProvider or none of the data in the InfoProvider. When securing reporting users, it is recommended that you define authorizations at a lower level than the InfoProvider.

Special Characteristics

Within the Technical Business Content, SAP provides so called special characteristics to enable implementation of analysis authorization concepts described earlier.

• 0TCAIPPROV grants authorization to data of specific InfoProviders
• 0TCAKYFNM grants authorization to specific key figures
• 0TCAACTVT grants authorization to activities on the data, for example Display (03) or Change (02) (in case of planning)
• 0TCAVALID grants authorization to data limited to specific time periods

The customer must first activate  Special Characteristics from Technical Business Content and then flag them as Authorization-Relevant in the InfoObject maintenance.

For more information, refer to:

• Analysis Authorizations:
• SAP Note 2318942: InfoObjects starting with 0TCA* cannot be edited in SAP BW modeling tools.

Securing Data Access on Characteristic InfoObject Level

Limiting users to data from a specific InfoProvider simplifies analysis authorization setup but restricts them to full or no data access within the InfoProvider.

To secure reporting users, you want to define authorizations on a lower level than InfoProvider. Suppose you wish two users to perform the same query but receive different results based on their responsibilities, secure analysis authorization down to the Characteristic InfoObject level. This option is the closest parallel to the field-level security in traditional SAP ERP or SAP S/4HANA.

Remember the prerequisite for securing data access on Characteristic InfoObject level is to flag them as Authorization-Relevant .

As shown in the preceding figure, Controller A and Controller B have nearly identical analysis authorizations. The only difference concerns the authorization-relevant characteristic 0CO_AREA (Controlling Area).

• Controller A is allowed to display data of 0CO_AREA = 1000 within InfoProvider COSTS_ACTUAL.
• Controller B is allowed to display data of 0CO_AREA = 2000 within InfoProvider COSTS_ACTUAL.

The users will only see data if the query selection meets their analysis authorizations.

They won't see data if the query selection meets their analysis authorizations only partially.

Analysis Authorization Check During Query Execution

A query always selects data from the InfoProvider. For the authorization-relevant characteristics, you have to ensure that the user performing the query has sufficient authorization for the complete selection of the query. Selection means the query's filter situation. Otherwise, no query result is displayed, but an error message indicates that the user doesn't have the required authorization.

Authorization Check OK: When the query selection is a proper subset of the authorization, query results are displayed.

Authorization Check Not OK: When the query selection is not a subset of the authorization, query results are not displayed, even if part of the selection is a subset of the authorization.

In general, the authorizations don't work as filters. Nevertheless, in the following instances when the user has partial analysis authorization only, the system still displays data.

• Authorized key figure values are displayed while unauthorized ones are omitted, showing only the key figures permitted for user access.
• Display hierarchies are automatically filtered on authorization, the nodes the user is authorized to see are displayed, the unauthorized nodes are not displayed.
• Variables filled from authorizations ("Authorization Variables") act like filters for the authorized values for the characteristics in question.

These three aspects are explained in the lessons Creating Analysis Authorizations for Key Figures, Creating Hierarchy Authorizations, and Using Variables in Authorizations.

Log in to track your progress & complete quizzes

How to Create Authorization Object and Object class in SAP Using SU21

Last Updated on August 11, 2022 by admin

Create a New Authorization Object in SAP

The following SAP security training tutorials guide how to create authorization objects in SAP step by step. In our previous training tutorials, we have learnt about an overview of authorization object and field values .

Refer to the below step-by-step procedure for how to define new authorization objects and Object classes in the SAP system.

Step 1: – Enter transaction code “SU21” in the SAP command field and press enter.

Step 2: – It is mandatory to create an object class and later we are going to assign it to authorization objects. On maintain authorization object screen, click on create button and then select object class.

Step 3: – On create authorization object class screen, update the following details.

• Object Class: – Enter the key that identifies the authorization object class in SAP systems.
• Text: – Update the descriptive text of the auth. object class.
• After updating details, click on the save button to save the configured object class.
• Author: – By default author field updated by the system, i.e user id of the responsible person.

Step 4: – Successfully we have created an object class in SAP systems . Now select object class and click on create and select authorization object as shown below.

On create authorization object screen, update the following details.

• Object: – Enter the new object id as per your organization requirements that identify the authorize object in SAP systems
• Text: – Update the descriptive text of the authorization object.
• Activity field: – Assign the authorization field to the custom authorization object , here we assigned the “ACTVT” field.

Now click on permitted activities and select the activities for field and select the save button. Here we selected activities of 01- create or generate, 02- change, 03- display, and 06- deleted.

Similarly, create objects and save the data. Successfully we have created a custom object class with authorization objects.

Create Authorization Model and App in SAP BTP, ABAP Environment

• How to create authorization fields
• How to create access controls
• How to edit authorization default values
• How to create IAM Apps and services
• How to create restriction fields and restriction types
• How to create business catalogs
• How to create restriction types

Prerequisites

• You need a SAP BTP, ABAP environment license.
• ADT version 2.96 or higher

In this tutorial, wherever XXX appears, use a number (e.g. 000 ).

Right-click on Z_ROOM_XXX , select the menu path New > Other ABAP Repository Object .

Search for Authorization Field , select it and click Next> .

Create your authorization field :

• Name: Z_LOCAFXXX

Click Next> .

Click Finish .

Edit your authorization field:

• Data Element: Z_LOCA_DTEL_XXX

Save and activate.

Search for Authorization Object , select it and click Next> .

Create your authorization object :

• Name: Z_LOCAOXXX
• Description: Location

Edit your authorization object and save it. The description and access category will appear then.

Search for Access Control , select it and click Next> .

Create your access control:

• Name: Z_I_ROOM_XXX
• Description: Room

Select Define Role with PFCG Aspect and click Finish .

Edit your service definition:

Switch to your behavior implementation, click CTRL + F and search for method validate. Edit following as your validate method.

Select your service binding Z_I_ROOM_BND_XXX and click Default Authorization Values .

Define following objects:

Search for IAM App , select it and click Next> .

Create your IAM App:

• Name: Z_ROOM_XXX

Select Services .

Add new services.

Find your service:

• Service Type: OData V2
• Service Name: Z_I_ROOM_BND_XXX_0001

Add _0001 to your service name to find it. Click OK .

Click Authorizations .

Select following activity. Therefore select Z_LOCAOXXX first and then type your instances and then the activity.

Right-click on your package Z_ROOM_XXX and select New > Other ABAP Repository Object .

Search for restriction field , select it and click Next > .

Create your restriction field:

• Name: Z_LOC_RF_XXX
• Description: Restriction field

Add Z_LOCAFXXX as authorization field, save and activate.

Search for restriction type , select it and click Next > .

• Name: Z_LOC_RT_XXX
• Description: Restriction type for location

Add Z_LOC_RF_XXX as restriction field AND Z_LOCAOXXX as restriction object.

Search for Business Catalog , select it and click Next> .

Create your business catalog:

• Name: Z_ROOM_BC_XXX

Select Apps .

Add new Apps.

Add your App:

• App ID: Z_ROOM_XXX_EXT
• Assignment ID: Z_ROOM_BC_XXX_0001

Click Publish Locally

Open your business catalog Z_ROOM_BC_XXX , add Z_LOC_RT_XXX as a restriction type, select write and click Publish Locally .

Where do you add your field values, for example like add, create, change, display etc.?

• authorization object
• access control
• Create authorization field
• Create authorization object
• Create access control
• Enhance behavior
• Edit authorization default values
• Create IAM app & add service
• Create restriction field and restriction type
• Create business catalog & add IAM app
• Create restriction type
• Test yourself

3470204 - How to identify where authorization objects come from

An authorization object or proposed field values are present in the Authorization tab of a role and there is a need to identify where this object or proposal comes from.

Ex.: Despite not having ME57 in the Menu of role, under Authorization tab Authorization object S_TCODE with field TCD can be found for the value ME57.

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Environment

SAP NetWeaver

Where-Used List, Authorization objects, Proposals, can't remove authorization object from role, wrong authorization objects, S_TCODE, S_START, S_SERVICE, S_DEVELOP , KBA , BC-SEC-AUT-PFC , ABAP Authorization and Role Administration , How To

About this page

Search for additional results.

Visit SAP Support Portal's SAP Notes and KBA Search .

Privacy | Terms of use | Legal Disclosure | Copyright | Trademark

Back-End Server: Assign OData Service Authorization to Users

The authorizations required for a particular application are provided via the OData service of the application. This includes the start authorizations for the service in the back-end system and the business authorizations for accessing business data displayed in the app. By adding the OData service to the menu of back-end PFCG roles, you add the start authorization and the authorization proposals for the business authorizations. You can adjust these according to your needs.

We recommend adding all services required by the apps in a certain catalog to the same role. This role can be either an existing role that fits to the scope of the catalog or a new role. If you add the services to an existing role, the authorization proposals have to be merged with the authorization values already defined in the role. You can consider using existing roles if the following applies:

The same users assigned to the role shall get access to the respective SAP Fiori apps.

The business authorizations already defined in the role and those that you define for the SAP Fiori apps do not contradict.

Run transaction Role Maintenance ( PFCG ) and create a new PFCG role or edit an existing role.

On the Menu tab, open the menu of the pushbutton for adding objects (+ pushbutton) and choose the object type Authorization Default .

From the Authorization Default menu, choose TADIR Service and enter the following data:

Program ID : R3TR

Object Type : IWSV

In the table, enter the name of the OData service.

For more information about the OData service for your app, see the app-specific documentation in the section SAP Fiori Apps .

Repeat steps 2 to 4 for all services of the catalogs that you want to authorize with the role.

On the Authorization tab, choose the pushbutton next to Profile Name to generate the authorization profile for the role.

Choose Change Authorization Data .

Choose Save and then Generate .

Run transaction User Maintenance ( SU01 ) and assign the role to the user.

If the user does not yet have the business authorizations required to use the app, perform the following steps:

Open transaction User Maintenance ( SU01 ).

On the Authorization tab, choose Generate Profile next to the profile name.

Choose Maintain Authorization Data .

On the Authorization Details screen, choose the Generate symbol.

Additional Steps for Fact Sheets

In addition to the OData service authorizations, the delivered back-end roles for fact sheets contain authorizations for the underlying search models. You can find the search model entries in transaction Role Maintenance ( PFCG ) under the Authorizations tab.

You must add entries to the authorization object S_ESH_CONN in the subtree Basis: Administration . Fill the following fields:

Request of Search Connector

Search Connector ID

You can enter a wildcard (*) in all four fields. Reason: The SAP-delivered authorization restrictions on search model level (field Template_Name ) are sufficient for search requests running in only one system and one client, as currently supported by SAP Fiori search.