Définit les actions d'autorisation pour les appels de protocole de modification et de requête du service de découverte par les clients de services Web pour une ressource spécifiée.
Définit les actions d'autorisation pour les appels de protocole de modification et de requête du service de profil personnel Liberty par les clients de services Web pour une ressource spécifiée.
Définit des actions d'autorisation du service Agent de stratégie URL. Il est utilisé pour définir des stratégies protégeant les URL HTTP et HTTPS. Il s'agit du cas d'emploi le plus fréquent de stratégies OpenSSO.
Actuellement, les agents de stratégie OpenSSO ne prennent en charge que les ressources http:// et https:// et n'acceptent pas les adresses IP à la place du nom d'hôte.
Les caractères génériques ne sont pas pris en charge pour le nom de protocole, d'hôte, de port et de ressource. Par exemple :
http*://*:*/*.html
Pour le service Agent de stratégie URL, si aucun numéro de port n'est spécifié, le numéro de port par défaut est 80 pour http:// et 443 pour https://.
Remarque – Les étapes 6 et 7 ne concernent pas les stratégies d'orientation.
LOOKUP (Service de découverte)
UPDATE (Service de découverte)
MODIFY (Service de profil personnel Liberty)
QUERY (Service de profil personnel Liberty)
GET (Agent de stratégie URL)
POST (Agent de stratégie URL)
Interaction pour l'acceptation — Appelle le protocole d'interaction Liberty pour l'acception d'une ressource. Cette option ne concerne que le type de service Profil personnel Liberty.
Interaction pour la valeur — Appelle le protocole d'interaction Liberty pour une valeur d'une ressource. Cette option ne concerne que le type de service Profil personnel Liberty.
Autoriser — Vous permet d'accéder à la ressource correspondant à celle définie dans la règle.
Refuser — Refuse l'accès à la ressource correspondant à celle définie dans la règle.
Les règles de refus ont toujours priorité sur les règles d'autorisation dans une stratégie. Par exemple, s'il existe deux stratégies pour une ressource donnée, l'une refusant l'accès et l'autre l'autorisant, le résultat sera un refus d'accès (sous réserve que les conditions des deux stratégies soient remplies). Il est conseillé d'utiliser les stratégies de refus avec un extrême prudence dans la mesure où elles peuvent engendrer des conflits potentiels entre les stratégies. Généralement, le processus de définition de stratégie ne doit utiliser que des règles d'autorisation d'accès et doit utiliser le refus par défaut lorsqu'aucune stratégie ne s'applique pour appliquer le refus.
Si des règles de refus explicites sont utilisées, les stratégies assignées à un utilisateur donné par le biais de différents objets (par exemple, l'appartenance à un rôle ou un groupe) peuvent entraîner le refus d'accès à une ressource même si une ou plusieurs stratégies autorisent l'accès. Par exemple, s'il existe une stratégie de refus pour une ressource applicable à un rôle Employé et une stratégie d'autorisation pour la même ressource applicable au rôle Responsable, les décisions stratégiques pour les utilisateurs auxquels sont assignés à la fois le rôle Employé et le rôle Responsable seront systématiquement un refus.
L'une des méthodes permettant de résoudre ce type de problème consiste à définir les stratégies à l'aide de plug-in de condition. Dans le cas ci-dessus, une condition de rôle appliquant la stratégie de refus aux utilisateurs authentifiés en tant qu'Employés et la stratégie d'autorisation aux utilisateurs authentifiés en tant que Responsables permet de différencier les deux stratégies. Une autre méthode consiste à définir la condition de authentication level dans laquelle le rôle Responsable est authentifié à un niveau supérieur.