Define las acciones de autorización para las invocaciones del protocolo de modificación y consulta de servicio de detección realizadas por los clientes de servicios Web para un recurso especificado.
Define las acciones de autorización para las invocaciones del protocolo de modificación y consulta de servicio de perfil personal Liberty realizadas por los clientes de servicios Web para un recurso especificado.
Define las acciones de autorización para el servicio de agente de directiva de URL. Se utiliza para definir las directivas que protegen las URL HTTP y HTTPS. Éste suele ser el uso más habitual de las directivas de OpenSSO.
Actualmente, los agentes de directivas de OpenSSO sólo admiten recursos http:// y https://, y no son compatibles con las direcciones IP especificadas en lugar del nombre de host.
Se admiten los comodines para el nombre de recurso, el protocolo, el host y el puerto. Por ejemplo:
http*://*:*/*.html
Al utilizar el servicio de agente de política de URL, si no se especifica ningún número de puerto, se utilizará el número de puerto predeterminado 80 para http:// y 443 para https://.
Nota – los pasos 6 y 7 no son aplicables para las políticas de referencia.
LOOKUP (Servicio de detección)
UPDATE (Servicio de detección)
MODIFY (Servicio de perfil personal Liberty)
QUERY (Servicio de perfil personal Liberty)
GET (Agente de directiva de URL)
POST (Agente de directiva de URL)
Interactuar para consentir: llama al protocolo de interacción de Liberty para obtener el consentimiento en un recurso. Esta opción sólo se utiliza con el tipo de servicio de perfil personal Liberty.
Interactuar para valor: llama al protocolo de interacción de Liberty para obtener un valor en un recurso. Esta opción sólo se utiliza con el tipo de servicio de perfil personal Liberty.
Permitir: permite el acceso al recurso que coincide con el que se ha definido en la regla.
Denegar: deniega el acceso al recurso que coincide con el que se ha definido en la regla.
Las reglas de denegación tienen siempre preferencia sobre las reglas de permiso en una política. Por ejemplo, si tiene dos políticas para un determinado recurso en las que una deniega el acceso y otra lo concede, el resultado será una denegación de acceso (si se cumplen las condiciones de ambas políticas). Se recomienda utilizar las políticas de denegación con extrema cautela, ya que pueden provocar conflictos entre las políticas. Normalmente, el proceso de definición de políticas sólo debería utilizar reglas de permiso y emplear la denegación predeterminada cuando no se aplique ninguna política para lograr la denegación.
Si se utilizan reglas de denegación explícitas, las políticas asignadas a un usuario mediante diferentes asuntos (como un rol y/o la pertenencia a un grupo) pueden provocar una denegación de acceso a un recurso, aunque haya una o varias políticas que permitan el acceso. Por ejemplo, si hay una política de denegación para un recurso aplicable a un rol de empleado y hay otra política de permiso para el mismo recurso aplicable al rol de administrador, se denegarán las decisiones de políticas asignadas a ambos roles.
Para solucionar problemas de este tipo, puede designar políticas utilizando los complementos de condiciones. En el ejemplo anterior, una "condición de rol" aplicada a la política de denegación de los usuarios autenticados en el rol de empleado y a la política de permiso de los usuarios autenticados en el rol de administrador puede ayudar a distinguir las dos políticas. También puede utilizar la condición authentication level en aquellas ubicaciones en las que el rol de administrador se autentique en un nivel superior.