Compartir a través de

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

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

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 usan identidad, roles o grupos. El remitente del mensaje se asigna a un conjunto de roles o grupos. La información de rol o grupo se usa para realizar 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 completo que la identidad, los roles o los grupos. El servicio web determina si un cierto usuario tiene acceso a un recurso protegido específico mediante el modelo robusto basado en declaraciones. Por ejemplo, un usuario puede leer información concreta, como la información de salario, a la que otros usuarios no tienen acceso.

Escenario 3: Mapeo de reclamaciones 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 de nombre de usuario o token kerberos. El servicio web es necesario para realizar comprobaciones de control de acceso de la misma manera, independientemente del tipo de credencial de usuario. Si se admiten tipos de credenciales adicionales con el tiempo, el sistema debe evolucionar en consecuencia.

Escenario 4: Determinar el acceso a varios recursos

Un servicio web intenta acceder a varios recursos. El servicio determina los recursos protegidos a los que un usuario determinado tiene acceso comparando las notificaciones asociadas al usuario con las notificaciones necesarias para acceder al recurso.

Términos del modelo de identidad

En la lista siguiente se definen los términos clave que se usan para describir los conceptos del modelo de identidad.

Directiva de autorización
Conjunto de reglas para mapear un conjunto de reclamos de entrada a un conjunto de reclamos de salida. La evaluación de la directiva de autorización resulta en la adición de conjuntos de reclamaciones a un contexto de evaluación y, posteriormente, a un contexto de autorización.

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

Reclamación
Una combinación de un tipo de reclamación, un derecho y un valor.

Conjunto de reclamaciones
Un conjunto de reclamaciones emitidas por un emisor determinado.

Tipo de reclamación
Una especie de reclamación. Las declaraciones definidas por la API del Modelo de Identidad son propiedades de la clase ClaimType. Algunos ejemplos de tipos de declaración proporcionados por el sistema son Dns, Email, Hash, Name, Rsa, Sid, Spn, System, Thumbprint, Uri, y X500DistinguishedName.

Contexto de evaluación
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 completada la evaluación.

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
Conjunto de información asociada a un contexto de evaluación o contexto de autorización.

Recurso protegido
Algo en el sistema que solo se puede usar, acceder a él o manipular de otro modo si se cumplen determinados requisitos por primera vez.

Derecha
Capacidad sobre un recurso. Los derechos definidos por identity Model API son propiedades de la Rights clase . Algunos ejemplos de derechos proporcionados por el sistema son Identity y PossessProperty.

Importancia
Algo sobre el que se reclama un derecho.

Reclamaciones

El modelo de identidad es un sistema basado en reclamaciones. Las afirmaciones describen las capacidades asociadas a alguna entidad del sistema, a menudo un usuario de ese sistema. El conjunto de reclamaciones asociadas a una entidad específica se puede considerar como una clave. Las reivindicaciones particulares definen la forma de esa clave, similar a una clave física que se usa para abrir una cerradura en 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 acceder a ese recurso con las notificaciones asociadas a la entidad que intenta acceder.

Una reclamación es la expresión de un derecho con respecto a un valor determinado. Un derecho podría ser algo como "Leer", "Escribir" o "Ejecutar". Un valor podría ser una base de datos, un archivo, un buzón o una propiedad . Las reclamaciones también tienen un tipo de reclamación. La combinación de tipo de reclamación y derecho proporciona el mecanismo para especificar capacidades 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 varios tipos y derechos de notificación se definen como parte del modelo de identidad, el sistema es extensible, lo que permite que los distintos sistemas, basándose en la infraestructura del modelo de identidad, definan tipos y derechos de notificación adicionales según sea necesario.

Reclamaciones de identidad

Un derecho concreto es el de la identidad. Los reclamos que poseen este derecho hacen una declaración sobre la identidad de la entidad. Por ejemplo, una notificación de tipo "nombre principal de usuario" (UPN) con un valor de someone@example.com y un derecho de Identity indica una identidad determinada en un dominio determinado.

Notificación de la identidad del sistema

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

Conjuntos de reclamaciones

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 reclamaciones 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.

En la ilustración siguiente se muestra un ejemplo de tres conjuntos de afirmaciones en los que un conjunto de afirmaciones tiene como emisor a otro conjunto de afirmaciones, que a su vez tiene el conjunto de afirmaciones del sistema como su emisor. Por lo tanto, los conjuntos de reclamaciones forman una jerarquía que puede ser arbitrariamente profunda.

Conjuntos de reclamaciones dentro de la jerarquía.

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

Varios conjuntos de notificaciones con el mismo conjunto de notificaciones que emiten.

Con la excepción de un conjunto de reclamaciones que es su propio emisor, el modelo de identidad no ofrece ningún soporte para que los conjuntos de reclamaciones formen un bucle. Por lo tanto, una situación en la que el conjunto de reclamaciones A se emite mediante el conjunto de reclamaciones B, que a su vez es emitido por el conjunto de reclamaciones A, nunca puede surgir. Además, el Modelo de Identidad no proporciona soporte para que los conjuntos de afirmaciones tengan varios emisores. Si dos o más emisores deben emitir un conjunto determinado de notificaciones, debe usar varios conjuntos de notificaciones, cada uno que contenga las mismas notificaciones, pero que tengan emisores diferentes.

El origen de las reclamaciones

Las reclamaciones pueden provenir de una variedad de orígenes. Un origen común de reclamaciones son las credenciales presentadas por un usuario, por ejemplo, como parte de un mensaje enviado a un servicio web. El sistema valida estas notificaciones y forman parte de un conjunto de notificaciones asociadas al usuario. Otros componentes del sistema también pueden ser orígenes de reclamaciones, incluidos, entre otros, el sistema operativo, la pila de red, el entorno 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 reclamaciones se generan como parte del proceso de evaluación de la política de autorización. Una directiva de autorización examina el conjunto (posiblemente vacío) de notificaciones existentes y puede optar por agregar notificaciones adicionales basadas en las notificaciones ya presentes e 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 política de autorización tiene acceso a una base de datos que incluye las fechas de nacimiento de las varias entidades que utilizan el sistema. La política de autorización utiliza esa información para añadir un atributo *Over18* al contexto. Tenga en cuenta que esta notificación de Over18 no divulga ninguna información sobre la entidad que no sea el hecho de que tiene más de 18 años de edad. Tenga en cuenta que la interpretación de la afirmación "Over18" depende de comprender la semántica de esa afirmación. La política de autorización que agregó la afirmación comprende esa semántica en algún nivel. El código que posteriormente examina las reclamaciones resultantes de la evaluación de políticas también será informado de esa semántica.

Una directiva de autorización determinada puede requerir que se evalúe varias veces porque, a medida que otras directivas de autorización agregan notificaciones, esa directiva de autorización podría agregar aún más notificaciones. Identity Model está diseñado para continuar la evaluación hasta que ninguna de las directivas de autorización activas agregue más afirmaciones al contexto. Esta evaluación continuada de las directivas de autorización evita la necesidad de aplicar un orden específico de evaluación con respecto a las directivas de autorización; se pueden evaluar en cualquier orden. Por ejemplo, si la directiva X solo agrega la notificación Z si la directiva A ha agregado la notificación B, si X se evalúa primero, inicialmente no agrega la notificación Z. Posteriormente, A se evalúa y agrega la notificación B. X se evalúa una segunda vez y esta vez agrega la notificación Z.

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

Una máquina Key-Making

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 usar para intentar abrir algunos bloqueos. La forma de la clave se almacena en un "contexto de autorización", creado por un administrador de autorización.

Contexto de autorización

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

Bloqueos

Si un contexto de autorización (un conjunto de declaraciones) es una clave, los requisitos que deben cumplirse para conceder acceso a un recurso protegido determinado constituyen la cerradura que debe ajustarse a la clave. El modelo de identidad no formaliza cómo se expresan estos requisitos, pero sí, dada la naturaleza basada en notificaciones del sistema, implica comparar las notificaciones en el contexto de autorización con algún conjunto de notificaciones necesarias.

Un 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 reclamaciones y es el resultado de evaluar una o varias directivas de autorización asociadas a un gestor de autorización. Estos conjuntos de reivindicaciones pueden examinarse para determinar si se han cumplido los requisitos de acceso. En la ilustración siguiente se muestran las relaciones entre estos diversos conceptos del modelo de identidad.

Gestión de reclamaciones y autorización xsi_recap

WCF y modelo de identidad

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

Programación del modelo de identidad

En la tabla siguiente se describe el modelo de objetos usado para programar extensiones del modelo de identidad. Todas estas clases existen en el espacio de nombres System.IdentityModel.Policy o System.IdentityModel.Claims.

Clase Descripción
Componente de autorización Clase Identity Model que implementa la IAuthorizationComponent interfaz .
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 Componente de autorización que contiene un conjunto de ClaimSet instancias con cero o más propiedades; el resultado de evaluar una o varias directivas de autorización.
Claim Combinación de un tipo de reclamación, derecho y 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. Implementación de la ClaimSet clase .
EvaluationContext Una clase base abstracta. Se pasa a una directiva de autorización durante la evaluación de la directiva.
IAuthorizationPolicy Interfaz derivada de IAuthorizationComponent e implementada por clases de directiva de autorización.
Rights Clase estática que contiene valores correctos 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 Clase sellada que proporciona varias propiedades relacionadas con el comportamiento de un servicio en lo que respecta a la autorización.
ServiceSecurityContext Clase que proporciona contexto de seguridad, incluido el contexto de autorización, para la operación actualmente en ejecución (o a punto de ejecutarse). Una instancia de esta clase forma parte de .OperationContext

Miembros significativos

Los siguientes miembros se usan normalmente para crear nuevos tipos de reclamación.

Miembro Descripción
CheckAccessCore Las clases derivadas implementan este método para realizar comprobaciones de acceso basadas en reclamaciones antes de ejecutar operaciones en un servicio. Cualquier información que se proporcione en OperationContext u otro lugar se puede examinar al tomar la decisión de verificación de acceso. Si CheckAccessCore devuelve true, se concede acceso y se permite ejecutar la operación. Si CheckAccessCore devuelve false, se deniega el acceso y la operación no se ejecuta. Para obtener un ejemplo, vea How to: Create a Custom Authorization Manager for a Service.
ServiceAuthorizationManager Devuelve ServiceAuthorizationManager para el servicio. El ServiceAuthorizationManager es responsable de tomar decisiones de autorización.
ExternalAuthorizationPolicies Colección de directivas de autorización personalizadas especificadas para el servicio. Estas directivas se evalúan junto a las directivas asociadas a las credenciales de los mensajes entrantes.

Consulte también