Show TOC

Security Enhancements for OData V4Locate this document in the navigation structure

In this section you can find information about security aspects which are relevant for OData version 4 (V4) for SAP Gateway Foundation.

For information about support of HTTP Strict Transport Security (HSTS), see 2202116 Information published on SAP site. See also 2042819 Information published on SAP site.

Authorization Aspects
Reduced Number of Authorization Checks
Compared to OData V2 the amount of authority checks have been reduced, and thus the performance has been optimized. This table describes the number of authority checks for OData V2 and OData V4 for co-deployed and none co-deployed scenarios:
Table 1:

OData in SAP Gateway Foundation

Co-Deployed

Non Co-Deployed

Version 2 (V2)

2

2

Version 4 (V4)

1

1

Because of historical reasons in OData V2, two checks are also necessary in a co-deployed scenario.

Authorization Object

The authorization check makes sure that the user has sufficient privileges to run the service from the service group. A service on OData V4 is a combination of services in a service group, and so this check is based on service group level. That means the finest granularity is access on service group and not on service level.

OData V4 in SAP Gateway Foundation uses the S_START authorization object instead of S_SERVICE like OData V2 does. There are several advantages to use S_START instead of S_SERVICE:

  • S_START is based on repository objects. The repository object for OData V4 is G4BA. If the administrator wants to allow the user access to all OData V4 services, he can use an asterisk and G4BA. With S_SERVICE it is not possible to limit an asterisk only to OData services.

  • An F4 help is available to search for different service groups by service group ID or the description of the service group. In the following picture you can see the F4 search help for service groups

  • S_START use the service group name. S_SERVICE created hash values for each entry. When you use transaction PFCG, to maintain roles for users, for each authority entry only a hash value is visible for S_SERVICE.

  • Application developers can use transaction SU22 to provide useful default values for different authority objects.

    • In the hub system, the repository objects are R3TR IWSG, and R3TR IWOM.

    • In the backend system all authorizations are collected in the repository object R3TR IWSV. For OData V4 the following objects are relevant: R3TR G4BA, and R3TR G4BS. So, in transaction SU22 you choose TADIR Service as Type of Application, R3TR as Program ID and G4BA as Object Type in a backend system.

      In addition to the authorizations maintained in the SU22 proposal, the role needs to have the authorization object S_START assigned with the following specifications:

      Table 2:

      Type of Application

      TADIR Service

      Program ID:

      R3TR

      Object Type:

      G4BA

      Object Name:

      Service Group ID

For registered service groups, one repository object exists: R3TR G4BA. This is the logical transport object for the transport of an OData V4 service group.

Role Templates

SAP Gateway Foundation provides predefined roles as templates for developers, administrators, end users, and support colleagues. You configure the roles based on the provided templates and assign users to the roles.

Role templates provide the administrator the possibility to have a bunch of necessary authorization objects for different user roles. The following role templates are expanded with authorization object S_START for OData V4:

  • /IWBEP/RT_BEP_ADM

  • /IWBEP/RT_MGW_ADM

  • /IWBEP/RT_MGW_USR

The administration transactions /IWFND/V4_ADMIN and /IWBEP/V4_ADMIN are secured by authorization object S_TCODE. These transaction codes are added to the BEP administration and the hub administration role template /IWFND/RT_ADMIN.
Related Information