This week we will focus on authorizations aspects, covering standard and non-standard solutions in SAPUI5 area. This article will focus on four major areas (they are essentially different in business and technical terms).

1.    SAP NetWeaver Gateway authorizations.

2.    SAP Fiori Launchpad authorizations

3.    ODATA Services authorizations

4.    Application authorizations

SAP NetWeaver Gateway authorizations

Since NetWeaver Gateway is (technically) a separate system (according to SAP’s recommendation) – the first thing to do is to give users “basic” authorizations according to their role in the system. These are templates that you can use in order to assign these authorizations.

1.    Standard users – /IWFND/RT_GW_USER

2.    Developers – /IWFND/RT_DEVELOPE

3.    Admins – /IWFND/RT_ADMIN

Here you can find further documentation about the authorization templates. As long as SAPUI5 users access functions in back end (SAP ECC) to extract information – authorization is required to execute functions on these systems (S_RFC object).

SAP Fiori Launchpad authorizations

SAP Fiori Launchpad authorizations are required for users using Fiori Launchpad, those authorizations are given to users in two different “menu” types. In addition, all users must have a ‘basic’ permission role – here you will find information about it.

Catalog

Catalog is object that contains ‘target mappings’ – access privileges for applications. Fiori Catalog is a general object for all applications whether it’s a standard or development one. Tiles settings allow you to navigate between applications across the Launchpad. Catalogs are used as ‘master data’ menu allowing users to access those catalogs through ‘App Finder’. System administrators can decide which applications will be on the default menu (group) when users enter to Launchpad.Even if your users are not using Fiori Launchpad yet – it is highly recommended to deliver their applications with Launchpad URL, in this case you will earn ability to manage authorizations, and use other features like Theme editor, app navigations and etc.

Group

A Group is basically a menu that contains tiles from different catalogs. Direct link between a catalog and group is not mandatory – users can have many available catalogs with tons of applications and only one group that defines the default. Usually a group will define a “persona” of a users.

Implementation and recommendations

·         First setup catalogs and groups though customization tools, and then assign them to standard PFCG authorization roles

·         We recommend creating catalogs based on business modules [finance / human resource / etc.] and create groups based on users roles [manager / sale man / etc.].

·         In addition to groups that can be given to users with Launchpad authorizations, each user can create their own groups and assign tiles to them from catalogs – so catalogs authorizations are actually more important than group authorizations. Users with undefined “role” can always create a group of their own

ODATA Services authorizations

Accessing of UI5 / Fiori Applications to source system is done through a layer called ODATA – you are probably familiar with it already. If not you can learn more about it in our blog. Each ODATA service is actually an access path to various functions in the system, therefore you need to secure it. The authorization for the ODATA services is given through a standard authorization object – ‘TADIR’, where the program name is ‘R3TR’ and program type is ‘IWSV’.

Application authorizations

If you are working on UI5 application that embeds authorizations inside [for example: presentation of components and capabilities according to authorizations] –you will need to define and develop an authorization mechanism for it. Suppose you want to allow different users to perform different actions in a UI5 screen – it is necessary to develop another layer of authorizations that will pull user’s authorizations from your source system and adjusts the applications to these authorizations accordingly.

Although the authorizations are usually addressed at the end of the project, we recommend pre-defining it before and map all your needs before you implement your solution. Initial authorization planning can provide flexibility in maintaining and managing the system at later stages, so don’t pass on it!