Verweigern – außer ACL

Erfahren Sie mehr über „Deny-es sei denn, ACLs“.

Verweigern – es sei denn, ACLs werden mit dem Ansatz „Deny-es“ ausgewertet. Die ACL definiert die Anwender, die NICHT abgelehnt werden. Auf andere Weise wird dem Anwender der Zugriff verweigert Es sei denn Die Rollen-, Bedingungs- und Skriptanforderungen sind erfüllt.

Wichtig:

Verweigern-es sei denn, ACLs haben Priorität gegenüber Allow-if-ACLs in der ACL-Auswertung, da sie zuerst ausgewertet werden.

Eine Ablehnung, es sei denn, die ACL führt zu zwei Ergebnissen

Auswertungsergebnis	Ergebnis
Bestanden	Die definierten Rollen, Datenbedingungen, Sicherheitsattribute und Skriptanforderungen werden erfüllt. Die ACL fährt mit der weiteren Auswertung fort Wichtig: Auch wenn eine Deny-Option (außer ACL) übereinstimmt, wird der Zugriff nur gewährt, wenn eine Allow-if-ACL dies explizit zulässt. Wenn keine Zulassen-wenn-ACL abgeglichen wird und die Ablehnen-es sei denn, die ACL besteht, gewährt das System standardmäßig Zugriff.
Fehlgeschlagen	Die Ablehnung – es sei denn, die ACL ist als fehlgeschlagen markiert, und der Zugriff wird verweigert.

Im Folgenden finden Sie ein erklärtes Beispiel für eine Deny-es sei denn, ACL:

• ACL hat Rollen sn_HR_Core.Manager Und itil
• Bedingung hat aktiv = Wahr
• Skript hat Antwort = gs.isLoggedIn();

Dem Anwender wird der Zugriff verweigert, es sei denn, alle drei Anforderungen für diese ACL sind erfüllt. Damit diese Ablehnung nicht bestanden wird, benötigt ein Anwender entweder die sn_HR_Core.Manager Oder itil Rollen zugreifen, auf einen Datensatz zugreifen, der das aktive Feld = aufweist Wahr , Und angemeldet sein. Verweigern-es sei denn, die ACL schlägt fehl, wenn eine der drei Anforderungen nicht erfüllt wird.