Roles and authorizations

Evaluate authorization errors

The Authorizations tab reads along with the recording of the OData console; it does not ask the page again and sends nothing. As soon as a request comes back with 401, 403 or an SAP message about authorization, service activation or system alias, a finding appears. The tab groups identical findings and counts them.

1. Open the FrontTailor panel in DevTools (F12) and choose the Authorizations tab.
2. Trigger the action that fails in the app.
3. Read the missing object with field and value in the finding and follow the next steps.
4. Pass the finding to the basis team with Copy as Markdown or Create ticket….

1. The finding: kind, request, service, missing object, message code, transaction ID, message and last occurrence.
2. Next steps with links such as Open SU53 and Open /IWFND/ERROR_LOG. They open SAP GUI for HTML of the same system – only on click.
3. Copy as Markdown and Download (.md) – per finding or for all.
4. Create ticket… opens the ticket dialog of the issue reporter with the finding, for example for ServiceNow.

It detects standard objects such as S_SERVICE and S_START and named objects (“authorization object Z_PRODUCT”), plus field and value (“activity 03” becomes ACTVT = 03) and named PFCG roles. It evaluates JSON (OData V2 and V4), XML and CAP errors, and parts of a $batch one by one. User ids never appear in clear text: DEVELOPER1 becomes D********1. Exports contain the page URL without query and hash.

Why don’t I see this tile?

The check chain in the same tab explains why a tile is missing in the launchpad. Since the tile cannot be seen, you enter its intent – suggestions come from the launchpad content; if the current hash holds an intent, it is pre-filled.

1. Open the Authorizations tab in the launchpad.
2. Enter the intent under Intent, for example SalesOrder-display.
3. Click Check. The chain runs stage by stage; the summary names the stage where the tile is blocked.

1. Check starts the chain for the intent entered.
2. The summary, here: no obstacle found in the launchpad client.
3. Stages that need PFCG or SU53 data are marked Backend service only – the browser does not guess.

If a launchpad version does not expose some information, the stage is Unknown – never Blocked. Every query has a time limit of 10 s. The chain only runs on click; the launchpad may then load its own modules and page content, and if the target app is not running, FrontTailor reads its manifest.json once from the same origin. For a visible tile, the Launchpad inspector is the right tool.

Roles tab and backend service

What the browser cannot know – PFCG roles, catalogs of the role, start authorization – comes from the ABAP add-on /CDNA/FIORITAILOR, a read-only OData V4 service for S/4HANA on-premise and Private Cloud. The Roles tab switches it on per host.

1. Open the app on the SAP system and the Roles tab in the panel.
2. Switch on Use backend service. Only now does FrontTailor send any request to the service – with your browser session, on the same host.
3. If the path differs from the default, enter it under Service path and click Apply.
4. The state changes to Available; below are system, client, user, add-on, contract and whether you may check other users.

1. Use backend service – only this switch is stored (and a different path), no answers, no users, no tokens.
2. The service’s state.
3. System, client, user, add-on, contract, Check other users and service URL.
4. User: empty for your own user, otherwise another one.

Without the service, FrontTailor works as before; the “Backend service only” stages stay open. When the service is available, Health also takes the ICF timeout from the system.

Role simulator: what does another user see?

1. Enter the user in the User and roles card. Before sending, the tab warns that the check is logged in the application log.
2. Click Show. Roles, catalogs, spaces, groups and reachable intents appear, each with the role that assigns it.
3. Click a reachable intent to start the check chain for this user – or enter an intent below under Why don’t I see this tile?.

1. The note before sending: checking another user is logged (SLG1, object /CDNA/FT).
2. The log number after the check.
3. The user’s roles.
4. Reachable intents with filter and assigning role.

1. Checked for – the simulated user.
2. The summary: The tile is blocked at: Catalog / content.
3. Start authorization with service and missing value, here S_SERVICE with SRV_NAME and SRV_TYPE.

For another user the backend answers catalog, role, target mapping and start authorization. Tile on a page and OData service only describe this browser’s user and stay Unknown in a simulation. For your own user, the Authorizations tab also uses the service once it is available.

Only users with the role /CDNA/FT_SIM (object /CDNA/SIM, activity 03) may check other users. The add-on writes every such check to SLG1 first – with caller, target user and intent or service. If it cannot save the entry, it refuses the check.

Typical problems