Fiori Security Part 1: Front-End vs Back-End Authorizations

📌 KEY POINTS
✅ Front-end roles grant launchpad content and permission to start OData services (S_SERVICE).
✅ Back-end roles grant authorization objects that protect business data and actions.
✅ In a hub deployment, these are in different systems; in embedded, both are in S/4HANA.
✅ CDS access controls (DCL) restrict data rows read through CDS-based services.
⚠️ Hiding a tile is not security — the service and data must be protected in the back end.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
This series covers Fiori security. Part 1 explains the layers.

━━━━━━━━━━━━━━━━━━━━
▶ 1. FRONT-END LAYER
To use an app, a user needs launchpad content (catalogs, spaces) and authorization to call the OData service, checked with authorization object S_SERVICE. In a hub deployment, this lives on the front-end server; in embedded deployment, in the S/4HANA system.

━━━━━━━━━━━━━━━━━━━━
▶ 2. BACK-END LAYER
When the service reads or changes data, classic authorization objects (for example company code or plant checks) and RAP or application checks decide what the user may see and do. These are the real protection of business data and must be designed carefully.

━━━━━━━━━━━━━━━━━━━━
▶ 3. CDS ACCESS CONTROLS
For CDS-based services, data control language (DCL) access controls add row-level restrictions automatically to selects, for example limiting sales orders to the user's sales organisation. Without a DCL, a CDS view may expose all rows if authorization check is not required.

━━━━━━━━━━━━━━━━━━━━
▶ 4. HUB VERSUS EMBEDDED
In a hub deployment, a central front-end server serves apps for several back ends; users need front-end roles there and back-end roles in each system, plus trusted connections. Embedded deployment simplifies administration because both layers live in S/4HANA.

━━━━━━━━━━━━━━━━━━━━
▶ 5. PRINCIPLE
The UI is never the security boundary. Hidden tiles or disabled buttons improve usability; the OData service, CDS access controls and back-end checks enforce security. Every app must be safe even if a user calls its service directly.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Identify the OData service of one app and its S_SERVICE entry.
2. Check the back-end authorization objects used by the service.
3. Find the DCL of the underlying CDS view.
4. Call the service directly as a restricted user and check results.

✅ CHECKPOINT: you can explain for one app what front-end and back-end authorizations protect.

A custom app hid a salary column in the UI for most users, but the OData service still returned it. A user opened the service URL in the browser and saw all salaries. The service was changed to check authorizations and exclude the field for unauthorised users, and a security review was added for custom services.

• Relying on hidden UI elements for security.
• CDS views without access controls.
• Forgetting S_SERVICE in roles.
• Hub setups without matching back-end roles.

• Security in services and back end.
• DCL for row-level restrictions.
• Paired front-end and back-end roles.
• Test services directly with restricted users.

Interviewers ask the difference between front-end and back-end authorizations, the role of S_SERVICE and CDS access controls, and why hiding UI elements is not security.