There are several security levels:

• Authentication check be on of the enabled authentication providers
• Static security based Spring-Security, and defining a simple Role Based Access Control. Pattern based URL are statics and cannot be easily changed at runtime. This security is the first firewall. Can only be updated by creating your own spring-security XML or Spring-Boot Java configuration.
• Dynamic security layer is provided by AuthorizingFilter, also a pattern based access control where roles, users and autorisations can be changed at runtime and backed in database. All roles and permissions can be updated at runtime with an immediate apply. You can manage this from /#/system/role and /#/system/user
• Organization Role Based Access Control are related to identity plugins derived from ligoj/plugin-id. These plug-ins map user from a repository like LDAP to groups and permissions.

All work with a deny all by default.

A set a information proving the identity of the principal.

An access to URLs and having the following properties:

• method: GET, POST, PUT, DELETE or _ null_ for all of them. Defined the HTTP method enabling this authorization.
• pattern: Regular expression of the URL to match:
  • .*: any URL
  • ^rest/.*: any REST URL
  • ^rest/my-resource/\d+: access to my-resource by their identifier only.
• type:
  • ui: This authorization is based on the fragment part of the URL
  • api: The URL corresponds to a REST access. The matched URL starts with the path without the context and includes the query parameters.

Simple logical name aggregating authorizations.

Unauthenticated users have the ROLE_ANONYMOUS role

A principal user

A principal user having an api authorization with the .* pattern.

A role associated to a user. A user can have any amount of role. The role USER (even if it is not defined) is granted to any authenticated user.

The authentication is first implied. The built-in authentication feature is based on x-api-key and x-api-user headers or parameters. When both are provided, they are checked. When only x-api-user or x-api-key is provided, they are ignored.

The api authorization is checked at server side for each REST access, and is partially used at browser side.

The ui authorization is based on the fragment part of the URL, so only checked by the browser. This is not really a security, and is only relevant to disable, hide or remove the UI component the principal should not see. You may notice this kind of authorization could be overridden by the user at the browser side. As base practices, this kind of authorization must be associated to a corresponding api authorization.

The ui security can be avoided by the user when he/she requests separately each JavaScript/CSS/HTML,... static resources, but the data are guarded by the api authorizations.

When the user profile is loaded, the authorizations (ui and api) are checked in the current DOM for the first load and then continuously when it is updated.
The watched components are :

• The current browser's URL itself: the location, visible in the navigation URL. When it is unauthorized, a security message is displayed, and the content is not loaded.
• The HTML components having href attribute
• The HTML components having data-secured-service, data-secured-role or data-secured-method attribute. See data-secured-*

The matched URL starts after the #/ fragment part. Samples: * ^system/bench: Browser URL #/system/bench * ^system/.*: Browser URL #/system

When a HTML component is unauthorized, by default its removed from the DOM. It is possible to control this behavior with data-security-on-forbidden="disable" attribute value.

When a HTML component contains only unauthorized components (buttons group, dropdown,...), it is also removed from the DOM. This process is recursively applied.

The data-secured-* attributes value corresponds to the related api usage the component depends on. For sample, having a chart displaying data collected from a REST URL should be displayed only when the REST service is authorized. Without this data-secured-service, the chart is displayed but with an empty content: still secured, but not really friendly.

<svg class="my-chart-displaying-secured-data"></svg>

SVG component is always displayed, even when the D3 ajax fails.

<svg class="my-chart-displaying-secured-data" data-secured-service="rest/financial/y2y"></svg>

SVG component is only displayed when api URL rest/financial/y2y is allowed.

<svg class="my-chart-displaying-secured-data" data-secured-role="FINANCE"></svg>

SVG component is only displayed when the principal as the role "FINANCE". This role can either be a static Spring-Security role, either an assigned role.

<svg class="my-chart-displaying-secured-data" data-secured-service="rest/financial/y2y" data-secured-method="GET"></svg>

SVG component is only displayed when api URL rest/financial/y2y is allowed with the GET method.

This the must simple control: each HTTP request to api endpoint is checked by this guard. The access is authorized when there is at least one couple {URL pattern, HTTP method} matching the HTTP request URL.

The matched URL starts after the context path, without the leading /, and includes the query part. Samples:

• .*: any URL, /rest, /manage (actuator), ... all endpoints
• ^rest/.*: any REST URL. Not actuator endpoint.
• ^rest/my-resource/\d+: access to my-resource by their identifier only.

Unauthorized access gets a 401 response.

For this real time URL access, the system uses caches. Therefore, if you want to update theses authorizations directly in the database, without using REST services, to need invalidate authorizations cache there /#/system/cache