Authorization
Role-Based Access Control (RBAC)
Every operational authorization within a NextGen Foundation-based application is governed by a Role-Based Access Control (RBAC) model.
According to this model, the operations of users, as well as REST or SOAP service clients, are subject to authorization depending on the authenticated identity. Each identity must be previously assigned to one or more groups (User Types), and each group must be pre-configured with a series of enabling permissions (Functions). A user's membership in one or more roles, along with the proper assignment of individual operational privileges to the various roles, allows for extremely granular configuration of the functionalities to which an authenticated entity has access.
The User Administrator role is responsible for defining these configurations and is a key role within the RBAC model. Upon initial deployment of the solution environment for a new tenant, a tenant administrator is automatically provisioned to establish the company's preferred authorization model.
While user and role management falls to administrators, permissions are pre-configured and immutable. These granular permissions are designed to facilitate specific operations within the system. Organized by namespaces in functional domain, subdomain, and resource, each permission name concludes with a verb indicating the allowed action. "view" and "edit" are common, but other verbs are used when the permission doesn't directly relate to data access.
Due to the extensive and function-specific nature of the permission set, role administration requires specialized FSM knowledge. Consequently, even with a working IdP authentication integration, this configuration is typically not delegated to enterprise user managers but remains within the Field Service Management solution.
Nevertheless, the NextGen configurable IdP integration allows for mapping SAML attributes or OAuth claims to roles, enabling centralized role management at the enterprise level.
With IdP integration, new users can be automatically registered and assigned a default role (e.g., guest) upon discovery. Further permission adjustments are then handled by the user administrator. For more complex scenarios, where the user should be ready to go at first access, a user administrator can manually register and configure users, or a batch integration should be put in place.
To know how to configure RS-Authorization on NextGen Foundation-based applications please refer to this documentation: https://overit-docs.atlassian.net/wiki/pages/createpage.action?spaceKey=NEXTGENFSM25R1&title=RS-Authorization
Access to Swagger Documentation
To access Swagger-UI, navigate to /api/api-docs.
Starting from NextGen FSM Wave 1, 2024 (release FSM 16.0.43 or Foundation 12.0.61), only authenticated users can access this page.
The property foundation.ms.doc.visibility controls access to the OpenAPI page as follows:
-
If the property is not configured (
nullvalue): Only authenticated users can access the OpenAPI documentation, without checking permissions. -
If the property is configured with an empty value: Everyone, including unauthenticated users, can access the OpenAPI documentation.
-
If the property is configured with specific permissions: Only authenticated users with those permissions can access the OpenAPI documentation.
This configuration allows administrators to manage API documentation visibility according to security policies.
To know more about XSRF handling with Swagger-UI please refer to this documentation: https://overit-docs.atlassian.net/wiki/pages/createpage.action?spaceKey=NEXTGEN&title=Improved%20XSRF%20handling%20with%20Swagger-UI