The Problem

Fiori applications should be role-based, but...

Sometimes we need role flavours...

Sometimes we need context-dependent roles...

Sometimes we just need the same app to adapt to the user roles...

In the end, we need the UI to also check the user roles or privileges. This should NOT replace proper authority checks in the backend.

A naive way

Simply treat the roles as any other type of data.

Read it from the backend (e.g. via a REST service).

Store it in a JSON or XML model.

Use the model to bind properties from the views.

Disadvantages

• Frontend and backend are coupled through the roles.
• All the views are polluted with the roles.
• Hard for developers to see what is affected by each role.

An example from SAP

We'll shortly look into an example from SAP: the SAP HANA XS Admin user interface.

In a nutshell, it uses this exact principle: a REST API for getting the roles, a JSON model for storing them and bindings to this model for adapting the UI.

This is what the REST API produces (and what is stored in the model):

And this is how they use it inside views:

A better way

App owned roles

The UI should have its own roles.

It should only work with its own roles and it should not "know" of any other roles.

Role adapters

The backend roles should be mapped into UI roles.

This should be done through one or more adapters (deployed in the UI or in the backend, but logically separate from both).

Each adapter should have the single responsability of doing this mapping.

Non-polluting changes

The logic for adapting the UI to the roles should not pollute the application code. It should be held centrally, in a separate file or package.

This logic should be built-up declaratively.

Advantages

• Frontend and backend are decoupled.
• It is a lot simpler to change the roles afterwards.
• More transparent to developers.

The library

The ui5-auth library can be used to declaratively define (via a json file) the app roles and adapt the UI based on them.

Role declarations

Can be done with a simple array of strings:

	"roles": ["A", "B", "C"]
	

Role relationships

Either implications or expressions can be used to compute assigned roles based on other roles:

	"implications": {
		"A": ["B"] // A implies B
	},
	"expressions": {
		"C": "{= ${A} && ${B} }" // C = A && B
	}

Actions

Actions can be used to adapt the UI based on the role values. Each action should define:

• when it should be applied
• what controls it should affect
• what should be done to the controls

Action Example

{
	"when": "missing:A",
	"views": ":all",
	"selector": {
		"type": "id",
		"value": "btnSmth" 
	},
	"action": {
		"type": "remove"
	}
}

Outlook

Create adapters for the most common scenarios (e.g. OData adapter).

Design a more fluent DSL for specifying the roles and actions.