Administración de notificaciones y autorización con el modelo de identidad

Artículo
06/02/2023

La autorización es el proceso de determinar qué entidades tienen permiso para cambiar, ver o tener acceso a un recurso informático. Por ejemplo, en una empresa, solo se puede permitir a los administradores el acceso a los archivos de sus empleados. Windows Communication Foundation (WCF) admite dos mecanismos para realizar el procesamiento de la autorización. El primer mecanismo le permite controlar la autorización utilizando construcciones de Common Language Runtime (CLR). El segundo es un modelo basado en notificaciones conocido como modelo de identidad. WCF usa el modelo de identidad para crear notificaciones a partir de mensajes entrantes; las clases del modelo de identidad se pueden ampliar a fin de admitir nuevos tipos de notificación para esquemas de autorización personalizados. En este tema se presenta información general de los conceptos de programación principales de la característica Modelo de identidad, así como una lista de las clases más importantes que la característica utiliza.

Escenarios del modelo de identidad

Los escenarios siguientes representan el uso del modelo de identidad.

Escenario 1: admisión de notificaciones de identidad, función y grupo

Los usuarios envían mensajes a un servicio web. Los requisitos de control de acceso del servicio web utilizan la identidad, las funciones o los grupos. El remitente del mensaje está asignado a un conjunto de funciones o grupos. Se utiliza la información de grupo o función para realizar las comprobaciones de acceso.

Escenario 2: admisión de notificaciones enriquecidas

Los usuarios envían mensajes a un servicio web. Los requisitos de control de acceso del servicio web requieren un modelo más enriquecido que la identidad, las funciones o los grupos. El servicio web determina si un usuario determinado tiene acceso a un recurso protegido determinado que utilice un modelo basado en notificaciones enriquecidas. Por ejemplo, un usuario puede ser capaz de leer información determinada, como información sobre el sueldo, a la que otros usuarios no tienen acceso.

Escenario 3: asignación de notificaciones dispares

Un usuario envía un mensaje a un servicio web. El usuario puede especificar sus credenciales de varias maneras diferentes: certificado X.509, token del nombre de usuario o token de Kerberos. Es necesario que el servicio web realice las comprobaciones de control de acceso de la misma manera, sin tener en cuenta el tipo de credencial del usuario. Si se admiten tipos de credenciales adicionales con el tiempo, el sistema debería evolucionar de la misma manera.

Escenario 4: determinar el acceso a varios recursos

Un servicio web intenta tener acceso a varios recursos. El servicio determina a qué recursos protegidos el usuario tiene acceso comparando las notificaciones asociadas con el usuario con las necesarias para tener acceso al recurso.

Condiciones del modelo de identidad

La lista siguiente define los términos clave utilizados para describir los conceptos del modelo de identidad.

Directiva de autorización
Conjunto de reglas para la asignación de un conjunto de notificaciones de entrada a un conjunto de notificaciones de salida. La evaluación de los resultados de la directiva de autorización da como resultado la adición de conjuntos de notificaciones a un contexto de evaluación y posteriormente un contexto de autorización.

Contexto de autorización
Un conjunto de conjuntos de notificaciones y cero o más propiedades. El resultado de evaluar una o varias directivas de autorización.

Notificación
Una combinación de un tipo de notificación, un derecho y un valor.

Conjunto de notificaciones
Un conjunto de notificaciones emitido por un emisor determinado.

Tipo de notificación
Un tipo de notificación. Las notificaciones definidas por la API del modelo de identidad son propiedades de la clase ClaimType. Los ejemplos de tipos de notificación proporcionados por el sistema son Dns, Email, Hash, Name, Rsa, Sid, Spn, System, Thumbprint, Uri y X500DistinguishedName.

Contexto de evaluación
Un contexto en el que se evalúa una directiva de autorización. Contiene propiedades y conjuntos de notificaciones. Se convierte en la base de un contexto de autorización una vez que la evaluación ha finalizado.

Notificación de identidad
Una notificación cuyo derecho es la identidad.

Emisor
Un conjunto de notificaciones que contiene por lo menos una notificación de identidad y se considera que ha emitido otro conjunto de notificaciones.

Propiedades
Un conjunto de información asociado a un contexto de evaluación o contexto de autorización.

Recurso protegido
Algo en el sistema que solo se puede utilizar, obtener acceso o manipularse si se cumplen ciertos requisitos primero.

Right
Capacidad sobre un recurso. Los derechos definidos por la API del modelo de identidad son propiedades de la clase Rights. Los ejemplos de derechos proporcionados por el sistema son Identity y PossessProperty.

Value
Algo sobre lo que se reclama un derecho.

Notificaciones

El modelo de identidad es un sistema basado en notificaciones. Las notificaciones describen las funciones asociadas con alguna identidad en el sistema, a menudo un usuario de ese sistema. El conjunto de notificaciones asociado a una entidad determinada puede pensarse como clave. Las notificaciones determinadas definen la forma de esa clave, similar a una llave física utilizada para abrir una cerradura de una puerta. Las notificaciones se utilizan para obtener acceso a los recursos. El acceso a un recurso protegido determinado se determina comparando las notificaciones necesarias para tener acceso a ese recurso con las notificaciones asociadas con la entidad que intenta tener acceso.

Una notificación es la expresión de un derecho con respecto a un valor en concreto. Un derecho podría ser algo como "Read", "Write" o "Execute". Un valor podría ser una base de datos, un archivo, un buzón o una propiedad. Las notificaciones también tienen un tipo de notificación. La combinación del tipo de notificación y el derecho proporciona el mecanismo para especificar las funciones con respecto al valor. Por ejemplo, una notificación de tipo "File", con el derecho "Read" sobre el valor "Biography.doc", indica que la entidad con la que está asociada dicha notificación tiene acceso de lectura al archivo Biography.doc. Una notificación de tipo "Name", con el derecho "PossessProperty" sobre el valor "Martin", indica que la entidad con la que está asociada dicha notificación posee una propiedad Name con el valor "Martin".

Aunque se definen varios tipos de notificación y derechos como parte del modelo de identidad, el sistema es ampliable, lo que permite a los distintos sistemas, que se crean en la parte superior de la infraestructura del modelo de identidad, definir tipos de notificación y derechos adicionales según sea necesario.

Notificaciones de identidad

Un derecho determinado sería el de la identidad. Las notificaciones que lo poseen realizan una instrucción sobre la identidad de la entidad. Por ejemplo, una notificación de tipo "nombre principal del usuario" (UPN) con un valor de someone@example.com y un derecho de Identity indica una identidad concreta en un dominio específico.

Notificación de la identidad del sistema

El modelo de identidad define una notificación de identidad: System. La notificación de la identidad del System indica que una entidad es la aplicación o sistema actual.

Conjuntos de notificaciones

El modelo de notificaciones que representan la identidad es importante porque las notificaciones siempre las emiten alguna entidad en el sistema, aun cuando esa entidad es en última instancia un concepto de "self". Las notificaciones se agrupan en un conjunto y cada conjunto tiene un emisor. Un emisor es, simplemente, un conjunto de notificaciones. Este tipo de relación recursiva debe finalizar en el futuro y cualquier conjunto de notificaciones puede ser su propio emisor.

La ilustración siguiente muestra un ejemplo de tres conjuntos de notificaciones donde un conjunto de notificaciones tiene, como su emisor, otro conjunto de notificaciones, que, a su vez, tiene el conjunto de notificaciones de sistema como su emisor. Por consiguiente, los conjuntos de notificaciones forman una jerarquía que puede ser profunda de manera arbitraria.

Sets of claims within the hierarchy.

Varios conjuntos de notificaciones pueden tener el mismo conjunto de notificaciones que emiten, tal y como se muestra en la siguiente ilustración:

Multiple sets of claims with the same issuing claim set.

Con la excepción de un conjunto de notificaciones que sea su propio emisor, el modelo de identidad no ofrece ninguna compatibilidad a los conjuntos de notificaciones para formar un bucle. Por tanto, una situación donde el conjunto de notificaciones A está emitido por el conjunto de notificaciones B, que a su vez está emitido por el conjunto A, nunca podrá darse. Asimismo, el modelo de identidad no proporciona ninguna compatibilidad para que los conjuntos de notificaciones tengan varios emisores. Si dos o más emisores deben emitir un conjunto determinado de notificaciones, a continuación, deberá utilizar varios conjuntos de notificaciones, cada uno con las mismas notificaciones, pero con distintos emisores.

El origen de las notificaciones

Las notificaciones pueden provenir de una gran variedad de orígenes. Un origen común de notificaciones son las credenciales presentadas por un usuario, por ejemplo, como parte de un mensaje enviado a un servicio web. El sistema valida tales notificaciones y se vuelven parte de un conjunto de notificaciones asociado con el usuario. Otros componentes del sistema también pueden ser orígenes de notificaciones, incluidos, aunque no limitados a ellos, el sistema operativo, la pila de red, el entorno de tiempo de ejecución o la aplicación. Además, los servicios remotos también pueden ser un origen de notificaciones.

Directivas de autorización

En el modelo de identidad, las notificaciones se generan como parte del proceso de evaluación de la directiva de autorización. Una directiva de autorización examina el (posiblemente vacío) conjunto de notificaciones existentes y puede optar por agregar notificaciones adicionales según las notificaciones ya presentes y la información adicional a su disposición. Esto proporciona la base de la asignación entre notificaciones. La presencia o ausencia de notificaciones en el sistema influye en el comportamiento de una directiva de autorización con respecto a si agrega notificaciones adicionales.

Por ejemplo, la directiva de autorización tiene acceso a una base de datos que incluye las fechas de nacimiento de las distintas entidades que utilizan el sistema. La directiva de autorización utiliza esa información para agregar una notificación de "Over18" al contexto. Tenga en cuenta que la notificación Over18 no divulga ninguna información sobre la entidad que no sea el hecho de que tenga más de 18 años. Tenga en cuenta que la interpretación de la notificación 'Over18' depende de comprender la semántica de esa notificación. La directiva de autorización que agregó la notificación comprende esa semántica en cierta medida. También se informará de esas semánticas al código que examina posteriormente las notificaciones que resultan de la evaluación de directivas.

Una directiva de autorización determinada puede requerir que se evalúe varias veces porque cuando otras directivas de autorización agregan notificaciones, esa directiva de autorización podría agregar aún más notificaciones. El modelo de identidad está diseñado para continuar la evaluación hasta que no se añada ninguna notificación más al contexto por parte de las directivas de autorización en vigor. Esta evaluación continua de las directivas de autorización impide al requisito aplicar cualquier orden de evaluación concreta con respecto a las directivas de autorización. Podrían evaluarse en cualquier orden. Por ejemplo, si la directiva X solo agrega la notificación Z si la directiva A ha añadido la notificación B, entonces si se evalúa X primero, no añade inicialmente la notificación Z. Posteriormente, se evalúa A y se añade la notificación B. X se evaluará una segunda vez y, en esta ocasión, añadirá la notificación Z.

Un sistema determinado puede tener muchas directivas de autorización en vigor.

Una máquina que crea claves

Evaluar un grupo de directivas de autorización asociadas es como usar una máquina que crea claves. Las directivas de autorización se evalúan una a una y se generan conjuntos de notificaciones, creando la forma de la clave. Una vez completada la forma de la clave, se puede utilizar para intentar abrir algunos bloqueos. La forma de la clave está almacenada en un "contexto de autorización", que crea un administrador de autorizaciones.

Contexto de autorización

Un administrador de autorizaciones evalúa las distintas directivas de autorización tal y como se ha descrito. El resultado es un contexto de autorización (un conjunto de conjuntos de notificaciones y algunas propiedades asociadas). Se puede examinar el contexto de autorización para determinar qué notificaciones están presentes en ese contexto, las relaciones entre las distintas notificaciones (por ejemplo, el conjunto de notificaciones que emite) y compararlas en última instancia con algunos requisitos que deben cumplir para tener acceso a un recurso.

Bloqueos

Si un contexto de autorización (un conjunto de notificaciones) es una clave, los requisitos que se deben satisfacer para conceder el acceso a un recurso protegido determinado constituyen el bloqueo que la clave debe ajustar. El modelo de identidad no formaliza cómo se expresan tales requisitos pero sí que, dada la naturaleza basada en notificaciones del sistema, supone la comparación de las notificaciones en el contexto de autorización contra algún conjunto de notificaciones necesarias.

Resumen

El modelo de identidad se basa en el concepto de notificaciones. Las notificaciones se agrupan en conjuntos y se agregan en un contexto de autorización. Un contexto de autorización contiene un conjunto de notificaciones y es el resultado de evaluar una o varias directivas asociadas con un administrador de autorizaciones. Se pueden examinar estos conjuntos de notificaciones para determinar si se han cumplido los requisitos de acceso. La siguiente ilustración muestra las relaciones entre estos distintos conceptos del modelo de identidad.

Managing claims and authorization

WCF y el modelo de identidad

WCF usa la infraestructura del modelo de identidad como base para realizar la autorización. En WCF, la clase ServiceAuthorizationBehavior permite especificar directivas de autorización como parte de un servicio. Tales directivas de autorización son conocidas como directivas de autorización externas y pueden realizar el procesamiento de las notificaciones según la directiva local o mediante interacción con un servicio remoto. El administrador de autorización, que representa la clase ServiceAuthorizationManager, evalúa las directivas de autorización externas junto con las directivas de autorización que reconocen los distintos tipos de credencial (tokens) y propaga lo que se denomina un contexto de autorización con las notificaciones adecuadas en un mensaje entrante. El contexto de autorización está representando por la clase AuthorizationContext.

Programación del modelo de identidad

La tabla siguiente describe el modelo de objetos utilizado para programar las extensiones del modelo de identidad. Estas clases existen todas en los espacios de nombre System.IdentityModel.Policy o System.IdentityModel.Claims.

Clase	Descripción
Componente de autorización	Una clase del modelo de identidad que implementa la interfaz IAuthorizationComponent.
IAuthorizationComponent	Interfaz que proporciona una única propiedad de cadena de solo lectura: Id. El valor de esta propiedad es único para cada instancia del sistema que implementa esta interfaz.
AuthorizationContext	Un componente de autorización que contiene un conjunto de instancias de `ClaimSet` con cero o más propiedades; el resultado de evaluar una o varias directivas de autorización.
Claim	Una combinación de un tipo de notificación, derecho y un valor. El tipo de notificación restringe el derecho y las partes del valor.
ClaimSet	Una clase base abstracta. Colección de instancias de `Claim`.
DefaultClaimSet	Una clase sellada. Una implementación de la clase `ClaimSet`.
EvaluationContext	Una clase base abstracta. Se pasa a una directiva de autorización durante la evaluación de la directiva.
IAuthorizationPolicy	Una interfaz derivada de `IAuthorizationComponent` y que implementan las clases de la directiva de autorización.
Rights	Una clase estática que contiene los valores de derecho predefinidos.

Las clases siguientes también se utilizan para la programación del modelo de identidad pero no se encuentran en los espacios de nombres System.IdentityModel.Policy ni System.IdentityModel.Claims.

Clase	Descripción
ServiceAuthorizationManager	Una clase que proporciona un método, CheckAccessCore, para realizar las comprobaciones de autorización basadas en notificaciones para cada operación en un servicio. Debe derivar de la clase e invalidar el método.
ServiceAuthorizationBehavior	Una clase sellada que proporciona varias propiedades relacionadas con el comportamiento de un servicio ya que pertenece a la autorización.
ServiceSecurityContext	Una clase que proporciona el contexto de seguridad, incluido el contexto de autorización, para la operación actualmente en ejecución (o que va a ejecutarse). Una instancia de esta clase es parte de OperationContext.

Miembros significativos

Los miembros siguientes se utilizan normalmente para crear nuevos tipos de notificación.

Miembro	Descripción
CheckAccessCore	Las clases derivadas implementan este método para realizar las comprobaciones de acceso basadas en notificaciones antes de ejecutar operaciones en un servicio. Se puede examinar cualquier información o toda ella en el OperationContext proporcionado, o en cualquier parte, cuando se realice la decisión de comprobación de acceso. Si CheckAccessCore devuelve `true`, después se obtiene el acceso y se permite que se ejecute la operación. Si `CheckAccessCore` devuelve `false`, después se deniega el acceso y la operación no se ejecuta. Para obtener más información, vea Procedimientos a fin de crear un administrador de autorización personalizado para un servicio.
ServiceAuthorizationManager	Devuelve ServiceAuthorizationManager para el servicio. ServiceAuthorizationManager es responsable de tomar decisiones de autorización.
ExternalAuthorizationPolicies	La colección de directivas de autorización personalizadas especificada para el servicio. Se evalúan estas directivas además de esas directivas asociadas con las credenciales en mensajes entrantes.