Legt die Autorisierungsaktionen für Discovery-Dienstanfrage- und Protokolländerungsaufrufe von Webdienst-Clients für eine bestimmte Ressource fest.
Legt die Autorisierungsaktionen für persönliche Liberty-Profildienstanfrage- und Protokolländerungsaufrufe von Webdienst-Clients für eine bestimmte Ressource fest.
Definiert Autorisierungsaktionen für den URL-Richtlinien-Agent-Dienst. Dieser Typ kommt bei der Definition von Richtlinien zum Schutz von HTTP- und HTTPS-URLs zum Einsatz. Dies ist die gebräuchlichste Verwendung von OpenSSO-Richtlinien.
Gegenwärtig unterstützen OpenSSO-Richtlinien-Agenten nur http://- und https://-Ressourcen und keine IP-Adressen anstelle des Hostnamens.
Platzhalter werden für Protokoll, Host, Port und Ressourcenname unterstützt. Beispiel:
http*://*:*/*.html
Der URL-Richtlinien-Agent-Dienst verwendet die Standardportnummer 80 für http:// und 443 für https://, falls keine Portnummern angegeben werden.
Hinweis – Schritt 6 und 7 gelten nicht für Bezugsrichtlinien.
LOOKUP (Discovery-Dienst)
UPDATE (Discovery-Dienst)
MODIFY (Persönlicher Liberty-Profildienst)
QUERY (Persönlicher Liberty-Profildienst)
GET (URL-Richtlinien-Agent)
POST (URL-Richtlinien-Agent)
Interaktion für Zustimmung: Ruft für eine Ressource das Liberty-Interaktionsprotokoll für Zustimmung auf. Diese Aktion ist nur auf den persönlichen Liberty-Profildienst anwendbar.
Interaktion für Wert: Ruft für eine Ressource das Liberty-Interaktionsprotokoll für einen Wert auf. Diese Aktion ist nur auf den persönlichen Liberty-Profildienst anwendbar.
Zulassen: Ermöglicht den Zugriff auf die Ressource, die mit der in der Regel definierten Ressource übereinstimmt.
Verweigern: Verweigert den Zugriff auf die Ressource, die mit der in der Regel definierten Ressource übereinstimmt.
Verweigerungsregeln haben stets Vorrang vor Zulassungsregeln in einer Richtlinie. Wenn Sie beispielsweise zwei Richtlinien für eine bestimmte Ressource haben, von denen eine den Zugriff verweigert und die andere den Zugriff erlaubt, dann wird der Zugriff verweigert (vorausgesetzt, dass die Bedingungen für beide Richtlinien erfüllt sind). Es wird empfohlen, die Verweigerungsrichtlinien mit äußerster Vorsicht zu verwenden, da sie zu möglichen Konflikten zwischen den Richtlinien führen können. In der Regel sollte der Richtliniendefinitionsprozess nur Zulassungsregeln verwenden und standardmäßig die Verweigerung anwenden, wenn keine Richtlinien vorhanden sind, um den Verweigerungsfall zu erfüllen.
Wenn explizite Verweigerungsregeln verwendet werden, können Richtlinien, die einem bestimmten Benutzer über verschiedene Betreffe zugewiesen wurden (wie Rollen- und/oder Gruppenmitgliedschaft) zu einem verweigerten Zugriff auf eine Ressource führen, auch wenn mindestens eine der Richtlinien den Zugriff erlaubt. Wenn beispielsweise eine Verweigerungsrichtlinie für eine auf eine Mitarbeiterrolle anwendbare Ressource vorhanden ist und eine Zulassungsrichtlinie für die gleiche Ressource für eine Managerrolle existiert, werden Richtlinienentscheidungen für Benutzer, denen sowohl eine Mitarbeiter- als auch eine Managerrolle zugewiesen wurde, verweigert.
Eine Möglichkeit, das Problem zu beheben, besteht darin, Richtlinien mit Bedingungs-Plugins zu entwickeln. Im obigen Beispiel würde eine ?Rollenbedingung“, die die Verweigerungsrichtlinie auf Benutzer, die sich für die Mitarbeiterrolle authentifizieren, und die Zulassungsrichtlinie auf Benutzer anwendet, die sich für die Managerrolle authentifizieren, helfen, die beiden Richtlinien zu unterscheiden. Eine andere Möglichkeit besteht darin, die authentication level-Bedingung zu verwenden, bei der die Managerrolle auf einer höheren Authentifizierungsebene authentifiziert wird.