SAP Fiori Security and Authorization

Why Fiori security matters

SAP Fiori is the modern user experience layer that fronts S/4HANA and the broader product portfolio. Fiori apps surface backend functionality through tiles in the launchpad, OData services on the gateway, and SAP backend role assignments. Without disciplined Fiori security the customer either over provisions catalogs to make adoption easy or under provisions catalogs and creates support burden through repeated access requests.

This article documents the catalog and group design, the OData service authorization, the launchpad role assignment, and the audit defensible Fiori security posture. Reference the SAP security audit pillar, the authorization concepts analysis, and the GRC and security expertise.

Catalog and group design

Catalogs are the Fiori containers that grant access to tiles and target mappings. Groups are the visual containers that organize tiles on the launchpad home page. A clean separation between catalogs and groups is the design principle. Catalogs grant authorization. Groups arrange the visual layout. The customer position is to define one catalog per business function and one group per persona view, never to mix the two responsibilities into a single object.

Reference the role design methodology, the authorization concepts analysis, and the user access review process.

OData service authorization

OData services expose the backend data and function to the Fiori frontend. Authorization at the OData layer rests on the S_SERVICE object and the backend authorization checks the service invokes. The audit defensible position grants S_SERVICE for the specific service name and version, never for wildcard. The backend authorization checks then apply on top, so a user with S_SERVICE for an OData service still needs the backend object authorization to read the data.

Reference the RFC security analysis, the critical authorizations analysis, and the cybersecurity analysis.

Wildcard S_SERVICE assignment is the most common Fiori audit finding and the most exploitable. Replacing wildcard with explicit service names reduces the audit risk and the attack surface in a single change.

Launchpad role assignment

Launchpad role assignment is the operating step that grants a user the Fiori catalogs and groups for the role. Roles in S/4HANA are composite. The composite role bundles the backend single roles, the OData S_SERVICE authorizations, the Fiori catalog assignment, and the Fiori group assignment into a single assignable unit. The customer position is to design composite roles by persona, not by department, so that role assignment scales with workforce changes.

The detail is in our role design methodology, the GRC implementation analysis, and the license audit pillar (cross cluster reference for the named user implication of Fiori role design).

Audit defensible Fiori posture

The audit defensible Fiori security posture has four components. First, documented catalog inventory with business owner and approval evidence. Second, explicit OData service authorization with no wildcard S_SERVICE. Third, composite role design by persona with documented mapping to single roles. Fourth, the quarterly user access review that recertifies catalog membership against role. The four components together survive external auditor walkthrough and SoX testing.

The implementation detail is in our security baseline analysis, the user access review process, the patch management analysis, and the compliance framework pillar. The GRC and security expertise documents the full senior advisor methodology.