Authentication and Authorization in BPC
BPC uses external identity providers (IdPs). Authentication and authorization always take place through these providers.
To find out which IdPs are supported, visit Creating, Configuring, and Using an Identity Provider.
Access Management
Access management in the BPC is organized by assigning individual users to organizations, roles, and permissions.
User assignments are typically made in your Identity Provider. In exceptional cases, this can also be supplemented via the IdentityProvider_Mappings setting by assigning organizations, roles, and permissions.
Logged-in users have a so-called session in the BPC context that contains all information regarding assigned organizations, roles, and permissions. The BPC modules can access this information and use it to control access to data and functions.
Users can view the organizations, roles, and permissions assigned to them via the Account module.
|
In BPC, the system ignores case sensitivity for organizations, roles, and permissions.
This means that the role |
Organizations
In BPC, an organization is a grouping attribute for users that usually corresponds to the organizational structure of the company using the system.
Depending on the IdP used, other terms may be used there, such as Gruppe or Benutzergruppe.
You can find out how to map these grouping attributes to BPC organizations in the respective IdP configuration.
Active and Inactive Organizations
You have the option to distinguish between active and inactive organizations. In this case, the IdP can additionally assign inactive organizations to the user during login. Inactive organizations initially have no effect on visibility or permissions. However, You can set an organization as active via the plugin Changing the Active Organization or the user information page. In this case, BPC will rebuild the user’s session, set the active organization, and treat all other organizations as inactive. This can subsequently affect the user’s visibility settings and permissions.
Roles
Roles are another grouping feature. This is typically used to bundle various Permissions and assign them to users. A user’s roles are assigned to individual users via the IdP.
Special Role bpcuser
This role is assigned to every user who can successfully log in to the BPC. This role can be used, for example, via IdentityProvider_Mappings to assign Permissions to all users.
Special Role bpcadmin
This role implicitly includes all Permissions. This makes this role very powerful, and it should be used sparingly.
|
This role does not implicitly include any additional Organizations or Roles.
Therefore, if you set access restrictions at the level of Organizations or Roles, users with the role |
Permissions
A user’s permissions are also defined by the identity provider. Similar to roles and organizations, these are either assigned directly to the user or granted implicitly through the user’s assignment to a role or organization.
You can find details on which permissions are taken into account and how in the description for the respective module.
Assignment of Additional Roles and Permissions by the BPC Core
The BPC offers the option to assign additional roles and permissions to a user in addition to the permission objects from the external IdP. This is done via mapping to existing organizations, roles, and permissions. It can be used primarily for assigning BPC-internal application permissions.
Directory of available organizations/roles/permissions stored in BPC Core if the IdP does not support this
If an OIDC provider such as Microsoft Azure AD, AWS Cognito, or Keycloak (without an Admin Client connection) as your Identity Provider, no directory of roles, permissions, and organizations is available in the BPC front end. In this case, you can make them available via the IdP mapping of the respective IdP backend Connection.
For JAAS-based identity providers, permissions can be made available in this way.
User organizations, roles, and permissions stored in the BPC Core if the IdP does not support them
Some IdPs have limited functionality and, for example, do not offer permissions (Karaf) or do not allow new roles or permissions to be added (INUBIT). In this case, the BPC Core stores these mappings in the IdP mapping of the respective IdP backend Connection.
