Für die Zuordnung von Funktionsgruppen zu Berechtigungsgruppen müssen Sie zwei Datenbanksichten definieren. Die erste Datenbanksicht liefert die Zuordnung der Personen zu Funktionsgruppen. Die Datenbanksicht enthält die zwei Spalten UID_Person und FunctionGroup.
Beispiel:
create view custom_Person2Fu as
select uid_personHead as UID_Person, 'Kostenstellenverantwortliche' as FunctionGroup
from Profitcenter
where isnull(uid_personHead, '') > ' '
union all
select uid_personHead, 'Abteilungsleiter' as FunctionGroup
from Department
where isnull(uid_personHead, '') > ' '
Die zweite Datenbanksicht nimmt die Zuordnung der Funktionsgruppen zu den Berechtigungsgruppen vor. Diese Datenbanksicht enthält die zwei Spalten FunctionGroup und DialogGroup.
Beispiel:
create view custom_Fu2D as
select 'Kostenstellenverantwortliche' as FunctionGroup, '<UID_Custom_Dialoggroup_ChefP>' as DialogGroup
union all select 'Abteilungsleiter', '<UID_Custom_Dialoggroup_ChefD>'as DialogGroup
Richten Sie rollenbasierte Berechtigungsgruppen mit den notwendigen Berechtigungen ein.
TIPP: Eine rollenbasierte Berechtigungsgruppe kann von nicht-rollenbasierten Berechtigungsgruppen erben. Somit können Sie eine Vererbungshierarchie aufbauen, um die Berechtigungen einfacher zu vergeben.
Die Konfigurationsdaten zur Zuordnung von Funktionsgruppen zu Berechtigungsgruppen passen Sie wie folgt an:
<DialogUserDetect>
<FunctionGroupMapping
PersonToFunction = "custom_Person2Fu"
FunctionToGroup = "custom_Fu2D"
/>
</DialogUserDetect>
Verwandte Themen
Bei der Anmeldung eines Benutzers erfolgt eine Gültigkeitsprüfung. Über Einstellungen können Sie zusätzlich konfigurieren.
-
Um zu verhindern, dass Benutzer mit ihren bestehenden Verbindungen arbeiten, wenn sie seit ihrer Anmeldung deaktiviert wurden, führt das System zusätzliche Gültigkeitsprüfungen im definierten Zeitabstand aus. Die Prüfung erfolgt bei der nächsten Aktion auf der Verbindung nach einem festgelegten Intervall von 20 Minuten.
Das Intervall können Sie über den Konfigurationsparameter Common | Authentication | CheckInterval anpassen. Bearbeiten Sie den Konfigurationsparameter im Designer.
-
Die Anzahl der Sitzungen, die ein Benutzer innerhalb kurzer Zeit öffnen darf, ist begrenzt auf 10 Sitzungen in einer Minute.
Ist die Anzahl überschritten, erhält der Benutzer eine Fehlermeldung:
Sie haben sich in der letzten Minute zu häufig angemeldet. Bitte warten Sie einen Moment mit einer Neuanmeldung.
Bei lokaler Anmeldung erfolgt die Prüfung je Frontend. Bei Anmeldung über den Anwendungsserver erfolgt die Prüfung je Anwendungsserver.
Die Anzahl der Sitzungen können Sie über den Konfigurationsparameter Common | Authentication | SessionsPerUserAndMinute anpassen. Bearbeiten Sie den Konfigurationsparameter im Designer.
-
Legen Sie über den Konfigurationsparameter QBM | AppServer | SessionTimeout den Zeitraum in Stunden fest, nach dem nicht mehr benutzte Sitzungen eines Anwendungsserver geschlossen werden. Der Standardwert ist 24 Stunden. Bearbeiten Sie den Konfigurationsparameter im Designer.
Die Authentifizierungsmodule OAuth2.0/OpenID Connect und OAuth2.0/OpenID Connect (rollenbasiert) unterstützen den Autorisierungscodefluss für OAuth 2.0 und OpenID Connect. Detaillierte Informationen zum Autorisierungscodefluss erhalten Sie beispielsweise in der OAuth Spezifikation oder der OpenID Connect Spezifikation.
Um die OAuth2.0/OpenID Connect Authentifizierung zu nutzen
-
Erstellen Sie im Designer den Identitätsanbieter und die OAuth2.0/OpenID Connect Anwendungen beim Identitätsanbieter. Dazu wird im Designer ein Assistent angeboten.
-
Weisen Sie den Webanwendungen die OAuth2.0/OpenID Connect Anwendung zu.
Verwandte Themen
Die Webanwendung (oder Clientanwendung) fordert am Authorisierungsendpunkt den Autorisierungscode an. Über den Anmeldeendpunkt wird ein erweiterter Anmeldedialog aufgerufen, über den der Autorisierungscode ermittelt wird. Das Authentifzierungsmodul fordert ein Zugriffstoken vom Tokenendpunkt an. Zur Prüfung des Sicherheitstokens wird das Zertifikat herangezogen.
Dabei wird zunächst versucht, das Zertifikat aus der Konfiguration der Webanwendung zu ermitteln. Ist dies nicht möglich, werden die Einstellungen des Identitätsanbieters verwendet. Um das Zertifikat zur Prüfung der Token zu ermitteln, werden die Zertifikatsspeicher in folgender Reihenfolge abgefragt:
-
Konfiguration der OAuth 2.0/OpenID Connect Anwendung (Tabelle QBMIdentityClient)
-
Zertifikatstext (QBMIdentityClient.CertificateText) .
-
Subject oder Fingerabdruck aus dem lokalen Speicher (QBMIdentityClient.CertificateSubject und QBMIdentityClient.CertificateThumbPrint).
-
Zertifikatsendpunkt (QBMIdentityClient.CertificateEndpoint).
Zusätzlich werden das Subjekt oder der Fingerabdruck verwendet, um Zertifikate vom Server zur prüfen, wenn sie angegeben sind und nicht auf dem Server lokal existieren.
-
Konfiguration des Identitätsanbieters (Tabelle QBMIdentityProvider)
-
Zertifikatstext ((QBMIdentityProvider.CertificateText).
-
Subject oder Fingerabdruck aus dem lokalen Speicher (QBMIdentityProvider.CertificateSubject und QBMIdentityProvider.CertificateThumbPrint).
-
Zertifikatsendpunkt (QBMIdentityProvider.CertificateEndpoint)).
Zusätzlich werden das Subjekt oder der Fingerabdruck verwendet, um Zertifikate vom Server zur prüfen, wenn sie angegeben sind und nicht auf dem Server lokal existieren.
-
JSON-Web-Key-Endpunkt (QBMIdentityProvider.JsonWebKeyEndpoint).
Um das Benutzerkonto zu ermitteln, wird festgelegt über welchen Claim-Typ die Benutzerinformationen ermittelt werden und welche Informationen des One Identity Manager Schemas zur Suche des Benutzerkontos verwendet werden.
Die Authentifizierung über OpenID Connect baut auf OAuth 2.0 auf. Die OpenID Connect Authentifizierung benutzt dieselben Mechanismen, stellt aber die Benutzer-Claims in einem ID-Token oder über einen UserInfo-Endpunkt zur Verfügung. Für den Einsatz von OpenID Connect sind weitere Konfigurationseinstellungen erforderlich. Ist im Scope der Wert openid enthalten, verwenden die Authentifizierungsmodule OpenID Connect zur Authentifizierung.
Verwandte Themen
