To assign function groups to permissions groups you have to define two database views. The first database view shows the assignment of employees to function groups. The database view contains two columns, UID_Person and FunctionGroup.
Example:
create view custom_Person2Fu as
select uid_personHead as UID_Person, 'Cost center manager' as FunctionGroup
from Profitcenter
where isnull(uid_personHead, '') > ' '
union all
select uid_personHead, 'Department manager' as FunctionGroup
from Department
where isnull(uid_personHead, '') > ' '
The second database view assigns function groups to permissions groups. This database view contains two columns, FunctionGroup and DialogGroup.
Example:
create view custom_Fu2D as
select 'Cost center manager' as FunctionGroup, '<UID_Custom_Dialoggroup_ChefP>' as DialogGroup
union all select 'Department manager', '<UID_Custom_Dialoggroup_ChefD>'as DialogGroup
Set up role-based permissions groups with the required permissions.
TIP: A role-based permissions group can inherit from a non role-based permissions group. This allows you to build up an inheritance hierarchy to making it easier to grant permissions.
Change the configuration data for assigning function groups to permissions groups as follows:
<DialogUserDetect>
<FunctionGroupMapping
PersonToFunction = "custom_Person2Fu"
FunctionToGroup = "custom_Fu2D"
/>
</DialogUserDetect>
Related topics
When a user logs in, a validity check is run. Use the settings to configure additional options.
-
The system runs additional validity checks to prevent users from working with established connections, if they were deactivated after they logged in. The check takes place with next action on the connection after a fixed interval of 20 minutes.
You can adjust the interval in the Common | Authentication | CheckInterval configuration parameter. In the Designer, edit the configuration parameter.
-
The number of session that a user can open within a short time is limited to 10 session a minute.
If this number is exceeded, the user is sent an error message.
You have logged in too often in the last minute. Please wait a moment before you log in again.
This check is done for each front-end if the login is local. If the login is on the application server, it is checked for each application server.
You can modify the number of sessions in the Common | Authentication | SessionsPerUserAndMinute configuration parameter. In the Designer, edit the configuration parameter.
-
Use the QBM | AppServer | SessionTimeout configuration parameter to add the timeout in hours, after which inactive application server sessions are closed. The default value is 24 hours. In the Designer, edit the configuration parameter.
The OAuth2.0/OpenID Connect and OAuth2.0/OpenID Connect (role-based) authentication modules support the authorization code flow for OAuth 2.0 and OpenID Connect. For more information about the authorization code flow, see, for example, the OAuth Specification or the OpenID Connect Specification.
To use OAuth2.0/OpenID Connect authentication
-
In the Designer, create the identity provider and the OAuth2.0/OpenID Connect applications for the identity provider. A wizard is available in the Designer to assist in this process.
-
Assign the OAuth2.0/OpenID Connect application to the web applications.
Related topics
The web application (or client application) requests the authorization code at the authorization endpoint. The login endpoint is used to call an advanced login window, which serves to determine the authorization code. The authentication module requires an access token from the token endpoint and the certificate is required to check the security token.
In the process, an attempt is made to find the certificate from the web application configuration. If this is not possible, the settings of the identity provider are used. To find the certificate for testing the token, the certificate stores are queries in the following order:
-
Configuration of the OAuth 2.0/OpenID Connect application (QBMIdentityClient table)
-
Certificate text (QBMIdentityClient.CertificateText).
-
Subject or thumbprint from the local memory (QBMIdentityClient.CertificateSubject and QBMIdentityClient.CertificateThumbPrint).
-
Certificate endpoint (QBMIdentityClient.CertificateEndpoint).
In addition, the subject or thumbprint is used to check certificates from the server if they are specified and do not exist locally on the server.
-
Configuration of the identity provider (QBMIdentityProvider table)
-
Certificate text ((QBMIdentityProvider.CertificateText).
-
Subject or thumbprint from the local memory (QBMIdentityProvider.CertificateSubject and QBMIdentityProvider.CertificateThumbPrint).
-
Certificate endpoint (QBMIdentityProvider.CertificateEndpoint)).
In addition, the subject or thumbprint is used to check certificates from the server if they are specified and do not exist locally on the server.
-
JSON-Web-Key endpoint (QBMIdentityProvider.JsonWebKeyEndpoint).
To identify the user account, the system determines which claim type is used to find the user information and which information from the One Identity Manager schema is used to find the user account.
Authentication through OpenID is built on OAuth 2.0. The OpenID Connect authentication uses the same mechanisms, but makes the claims available either in an ID token or with a UserInfo endpoint. Other configuration settings are required for using OpenID Connect. If the Scope contains the openid value, the authentication module uses OpenID Connect for authentication.
Related topics
