XACML

Terminología no normativa (siguiendo la RFC 2904 , excepto para PAP)

1. Un usuario envía una solicitud para acceder a un recurso; esta solicitud es interceptada por el Punto de Aplicación de Políticas (PEP).
2. El PEP convierte la solicitud en una solicitud de autorización XACML.
3. El PEP remite la solicitud de autorización al Punto de Decisión de Políticas (PDP).
4. El PDP evalúa la solicitud de autorización en función de sus políticas configuradas. Estas políticas se obtienen a través de un Punto de Recuperación de Políticas (PRP) y son gestionadas por un Punto de Administración de Políticas (PAP). Si es necesario, el PDP también recupera los valores de los atributos de los Puntos de Información de Políticas (PIP) subyacentes.
5. El PDP toma una decisión (Permitir, Denegar, No aplicable o Indeterminado) y la devuelve al PEP.
6. El PEP impone la decisión de acceso en contra de la solicitud del usuario.

XACML está estructurado en los siguientes niveles de elementos:

• PolicySet (reemplazado por/fusionado en Policy en XACML 4.0),
• Política,
• Regla.

Hasta XACML 3.0, un PolicySet puede contener cualquier número de elementos PolicySet y/o Policy, y una Policy puede contener cualquier número de elementos Rule.

En XACML 4.0, una Política puede contener cualquier número de elementos de Política y/o Regla. Ya no existe distinción entre Política y Conjunto de Políticas.

Las políticas, las reglas y las solicitudes utilizan sujetos, recursos, entornos y acciones.

• Un elemento sujeto es la entidad que solicita acceso. Un sujeto tiene uno o más atributos.
• El recurso es aquello a lo que el usuario solicita acceder, por ejemplo, datos, un servicio o un componente del sistema. Un recurso tiene uno o más atributos.
• Un elemento de acción define el tipo de acceso solicitado al recurso. Las acciones tienen uno o más atributos.
• Un elemento del entorno puede proporcionar, opcionalmente, información adicional que no sea específica del sujeto, recurso o acción, pero que aún se encuentre en el contexto de la solicitud de acceso, por ejemplo, la fecha y hora actuales.

XACML proporciona un objetivo, que básicamente es una condición sobre los atributos del sujeto, recurso, acción o entorno que debe cumplirse para que una política o regla se aplique a una solicitud determinada. Una vez que se determina que una política se aplica a una solicitud, se evalúan sus reglas para determinar la decisión de acceso y la respuesta.

Además de permitir verificar la aplicabilidad, la información de destino también facilita la indexación de políticas, lo cual resulta útil si se necesita almacenar muchas políticas y luego revisarlas rápidamente para encontrar las que se aplican. Cuando llega una solicitud de acceso a ese servicio, el PDP sabrá dónde buscar las políticas que podrían aplicarse a dicha solicitud, ya que las políticas están indexadas según sus restricciones de destino. Cabe destacar que un destino también puede especificar que se aplica a cualquier solicitud.

Las políticas y las reglas pueden contener elementos objetivo.

Las condiciones solo existen en las reglas. Las condiciones son esencialmente expresiones booleanas que pueden usar los operadores AND, OR, NOT y una amplia gama de funciones que se pueden usar para comparar dos o más atributos, por ejemplo, subject-id==doctor-id.

Hasta XACML 3.0, las condiciones son una forma más avanzada de objetivos, mientras que en XACML 4.0 son lo mismo. ^{[ 8 ]}

En determinadas circunstancias, es posible implementar controles de segregación de funciones o control de acceso basado en relaciones.

Dentro de XACML, se puede utilizar un concepto llamado obligaciones. Una obligación es una directiva del punto de decisión de política (PDP) al punto de aplicación de política (PEP) sobre lo que debe realizarse antes o después de que se apruebe un acceso. Si el PEP no puede cumplir con la directiva, el acceso aprobado puede o no debe realizarse. La ampliación de las obligaciones elimina la brecha entre los requisitos formales y la aplicación de políticas. Un ejemplo de obligación podría ser el siguiente:

Regla de control de acceso: Permitir el acceso al recurso MedicalJournal con el atributo patientID=x si el sujeto coincide con el médico designado del paciente y se lee la acción con obligación en Permitir: doLog_Inform(patientID, Subject, time) En caso de denegación: doLog_UnauthorizedLogin(patientID, Subject, time)

La obligación que ofrece XACML puede ser una forma eficaz de cumplir con los requisitos formales ( como el no repudio ) que resultan difíciles de implementar como reglas de control de acceso. Además, cualquier requisito formal se integrará en la política de control de acceso como una obligación, y no como una función independiente, lo que facilita la coherencia de las políticas y la centralización del entorno de TI.

Las obligaciones pueden utilizarse para situaciones de emergencia o para aumentar la confianza ("no se pueden transferir 1000 dólares sin autenticación de dos factores; aquí tiene el enlace a la página de 2FA").

Además de las obligaciones, la XACML respalda las recomendaciones que son idénticas a las obligaciones, con la diferencia de que una PEP no está obligada a hacer cumplir dichas recomendaciones (de ahí su nombre).

Consulte la norma para obtener una definición formal de estas funciones.

• sumar (doble y entero)
• restar (números dobles y enteros)
• multiplicar (doble y entero)
• dividir (números dobles y enteros)
• módulo (doble y entero)
• absoluto (doble y entero)
• redondo
• piso

Consulte la norma para obtener una definición formal de estas funciones.

• concatenar cadenas
• cadena-comienza-con
• termina-de-cadena
• cadena-contiene
• cadena-subcadena

La lista de funciones de orden superior se muestra a continuación. Para una definición formal, consulte el estándar XACML.

• anyOf ( urn:oasis:names:tc:xacml:3.0:function:any-of )
  • parámetros: anyAtomicOrBag anyAtomicOrBag*
  • valor de retorno: booleano
  • Descripción: esta función recibe como parámetro una función booleana y dos o más valores de atributos o conjuntos. La función de orden superior aplica la función booleana a los parámetros restantes.
  • Ejemplo: anyOf(function[stringEqual], allowedRoles, stringOneAndOnly(role))devolverá verdadero si (a) rol es de valor único, (b) hay al menos un valor en el contenedor de atributos allowedRoles igual al valor dentro del contenedor de atributos de valor único role.
• allOf ( urn:oasis:names:tc:xacml:3.0:function:all-of )
  • parámetros: anyAtomicOrBag anyAtomicOrBag*
  • valor de retorno: booleano
• anyOfAny ( urn:oasis:names:tc:xacml:3.0:function:any-of-any )
  • parámetros: anyAtomicOrBag anyAtomicOrBag*
  • valor de retorno: booleano
• allOfAny ( urn:oasis:names:tc:xacml:1.0:function:all-of-any )
  • parámetros: bag[anyAtomic] bag[anyAtomic]
  • valor de retorno: booleano
• cualquieraDeTodos ( urn:oasis:names:tc:xacml:1.0:function:cualquier-de-todos )
  • parámetros: bag[anyAtomic] bag[anyAtomic]
  • valor de retorno: booleano
• allOfAll ( urn:oasis:names:tc:xacml:1.0:function:all-of-all )
  • parámetros: bag[anyAtomic] bag[anyAtomic]
  • valor de retorno: booleano
• mapa ( urn:oasis:names:tc:xacml:1.0:function:map )
  • parámetros: anyAtomicOrBag anyAtomicOrBag*
  • valor de retorno: bag[anyAtomic]

https://docs.oasis-open.org/xacml/acal/xacml/core/v4.0/csd01/ ^{[ 8 ]}

https://docs.oasis-open.org/xacml/acal/xacml/profiles/ ^{[ 8 ]}

Véase también la variante JSON (JACAL):

https://docs.oasis-open.org/xacml/acal/jacal/

http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd

• http://www.w3.org/2001/XMLSchema#anyURI
• http://www.w3.org/2001/XMLSchema#base64Binary
• http://www.w3.org/2001/XMLSchema#boolean
• http://www.w3.org/2001/XMLSchema#date
• http://www.w3.org/2001/XMLSchema#dateTime
• http://www.w3.org/2001/XMLSchema#dayTimeDuration
• http://www.w3.org/2001/XMLSchema#double
• http://www.w3.org/2001/XMLSchema#hexBinary
• http://www.w3.org/2001/XMLSchema#integer
• http://www.w3.org/2001/XMLSchema#string
• http://www.w3.org/2001/XMLSchema#time
• http://www.w3.org/2001/XMLSchema#yearMonthDuration
• urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name
• urn:oasis:names:tc:xacml:1.0:data-type:x500Name
• urn:oasis:names:tc:xacml:2.0:data-type:dnsName
• urn:oasis:names:tc:xacml:2.0:data-type:ipAddress
• urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression

JACAL ^{[ 5 ]} 1.0 está alineado con XACML 4.0 ya que comparte el mismo modelo agnóstico ACAL ^{[ 9 ]} .

ALFA significa Lenguaje Abreviado para la Autorización. Es una sintaxis ligera que se utiliza para implementar políticas de control de acceso basadas en políticas. Para ver ejemplos, consulte el artículo principal .

El perfil JSON de XACML ^{[ 10 ]} simplifica la integración entre el PEP y el PDP.

XACML es casi exclusivamente un lenguaje de definición de políticas basado en XML , definido por una especificación abierta de OASIS . La especificación XACML no abarca el diseño ni la implementación de los Puntos de Decisión de Políticas (PDP), sino únicamente el lenguaje de políticas que estos utilizan. Muchos PDP, tanto propietarios como de código abierto, emplean XACML como su lenguaje de definición de políticas.

Open Policy Agent (OPA) es una implementación de código abierto de Policy Decision Point (PDP), capaz de interpretar el lenguaje de las políticas para tomar decisiones políticas. OPA es una implementación de PDP de propósito general que se puede utilizar en cualquier escenario donde se requiera una decisión política, al igual que las implementaciones de PDP que admiten la especificación XACML.

El lenguaje de definición de políticas de OPA es (Rego), que es un lenguaje incompleto de Turing basado en JSON basado en Datalog .

El proyecto xacml-with-opa muestra cómo admitir el perfil JSON de XACML 3.0 ^{[ 10 ]} con OPA.

Las políticas XACML pueden ser traducibles a Rego, pero no siempre, debido a ciertas limitaciones de Rego, tales como:

• Sin soporte para XML/XPath ( problema OPA n.° 7361 );
• No hay operador OR ( problema OPA n.° 7602 );
• No se permite lógica AND/OR anidada en las reglas ( problema OPA n.° 3183 );
• Uso limitado del operador NOT ( problema OPA n.° 3924 ).

SAML es un estándar de federación y SSO de identidad utilizado para la autenticación. SAML se utiliza como formato común de token de identidad entre diferentes aplicaciones. Tanto SAML como XACML están definidos por OASIS . SAML y XACML fueron diseñados para interoperar: SAML se utiliza para transmitir información de identidad/identidades virtuales y XACML para gestionar la lógica de control de acceso mediante políticas.

OAuth 2.0 se considera un estándar de autorización. Sin embargo, difiere de XACML en su origen, su propósito y sus aplicaciones. OAuth se basa en:

• Control de acceso delegado: Yo, el usuario, delego el acceso de otro usuario o servicio al recurso del que soy propietario. Por ejemplo, mediante OAuth, otorgo a Twitter (el servicio) la capacidad de publicar en mi muro de Facebook (el recurso).
• Cómo gestionar el antipatrón de contraseñas . En un modelo tradicional, al integrar dos servicios, es necesario proporcionar al servicio B las credenciales de usuario del servicio A para que este pueda suplantar la identidad del usuario ante el servicio A. Esto conlleva numerosos riesgos. El uso de OAuth elimina estos problemas y permite al usuario controlar las acciones que el servicio B puede realizar en su nombre ante el servicio A.
• Servicios/recursos basados ​​en HTTP
• aprobación del propietario (usuario) gestor

XACML no gestiona la aprobación de usuarios, el acceso delegado ni la administración de contraseñas. XACML simplemente proporciona:

• Una arquitectura de control de acceso con el concepto de Punto de Decisión de Política (PDP), como se mencionó anteriormente, y un Punto de Aplicación de Política (PEP).
• un lenguaje de políticas con el que expresar una amplia gama de políticas de control de acceso, incluidas políticas que pueden utilizar consentimientos gestionados/definidos a través de OAuth.

XACML y OAuth se pueden combinar para ofrecer un enfoque más completo para la autorización.