El papel del motor de notificaciones

En su máximo nivel, el motor de notificaciones de Servicios de federación de Active Directory (AD FS) es un motor basado en reglas que se dedica a servir y procesar solicitudes de notificación para el Servicio de federación. El motor de notificaciones es la única entidad dentro del Servicio de federación que se encarga de ejecutar cada uno de los conjuntos de reglas en todas las relaciones de confianza federadas que ha configurado y de entregar el resultado de salida a la canalización de notificaciones.

Aunque la canalización de notificaciones es más un concepto lógico del proceso de un extremo a otro para el flujo de notificaciones, las reglas de notificación son un elemento administrativo reales que puede usar para personalizar el flujo de notificaciones durante el proceso de ejecución de las reglas de notificación. Para más información sobre el proceso de canalización, consulte The Role of the Claims Pipeline.

Como se muestra en la ilustración siguiente, el motor de notificaciones se ocupa de aceptar notificaciones entrantes (reglas de aceptación), autorizar a los solicitantes de notificaciones (reglas de autorización) y emitir notificaciones salientes (reglas de emisión) mediante reglas de notificación en todas las relaciones de confianza federadas de su organización.

Proceso de ejecución de reglas de notificación

Al configurar una relación de confianza de proveedores de notificaciones o una relación de confianza para usuario autenticado en su organización con reglas de notificación, los conjuntos de reglas de notificación para esa relación de confianza actúan como un equipo selector para las notificaciones entrantes al invocar el motor de notificaciones para que aplique la lógica necesaria en las reglas de notificación y así determinar si se emiten notificaciones y cuáles se deben emitir.

En la siguiente sección se describen los pasos que se producen en el motor durante el flujo de notificaciones a través del proceso de ejecución de reglas de notificación. Cada uno de los pasos que se detallan a continuación se produce en cada fase que se describe en el proceso de canalización de notificaciones. Estos pasos incluyen:

• Paso 1: inicialización.

• Paso 2: ejecución.

• Paso 3: resultado de la ejecución.

Para más información sobre el proceso de canalización, consulte The Role of the Claims Pipeline.

Paso 1: inicialización.

En el primer paso del proceso de ejecución de reglas de notificación, el motor de notificaciones acepta notificaciones entrantes agregándolas primero al conjunto de notificaciones de entrada. Un conjunto de notificaciones de entrada es similar a una memoria caché en cuanto a que la memoria se usa para almacenar temporalmente datos únicamente cuando un proceso requiere que los datos estén disponibles para su recuperación. Los datos del conjunto de notificaciones de entrada se descartan cuando finaliza la ejecución de la regla.

Adición de una notificación al conjunto de notificaciones de entrada de un conjunto de reglas

El motor de notificaciones crea el conjunto de notificaciones de entrada cuando necesita almacenar temporalmente datos de notificación en la memoria mientras procesa la lógica asociada a un conjunto de reglas de notificación. El motor de notificaciones copia todas las notificaciones entrantes al conjunto de notificaciones de entrada donde se pueden recuperar mediante la primera regla del conjunto de reglas.

Por ejemplo, en la ilustración siguiente, el motor de notificaciones lee las notificaciones de A y B a partir de las notificaciones entrantes y las copia en el conjunto de notificaciones de entrada. Cuando se encuentran en el conjunto de notificaciones de entrada, el motor de notificaciones recupera y procesa las notificaciones A y B como entradas para la lógica en la primera regla del conjunto de reglas de notificación.

Todas las reglas de un conjunto de reglas de notificación comparten el mismo conjunto de notificaciones de entrada. Cada regla de ese conjunto puede agregarse al conjunto de notificaciones de entrada compartida, por lo que afectará a todas las reglas sucesivas del conjunto.

Paso 2: ejecución.

En este paso del proceso de las reglas de notificación, estas se procesan cuando el motor de notificaciones recorre cronológicamente todas las reglas dentro de un conjunto de reglas determinado, una a una. Cada regla dentro de un conjunto de reglas solo se ejecuta una vez y en el orden en que aparecen de arriba a abajo, tal y como se muestran en el cuadro de diálogo Editar reglas de notificación del complemento Administración de AD-FS. La regla de notificación que se encuentra en la parte superior del conjunto de reglas se procesa en primer lugar y, luego, se procesan las reglas posteriores hasta que todas se hayan ejecutado.

Tal y como se define en el lenguaje de reglas de notificación, una regla de notificación consta de dos partes: la condición y la instrucción de emisión. El motor de notificaciones primero procesa la parte de la condición, para lo que usa los datos del conjunto de solicitudes de entrada para determinar si se cumple la condición especificada dentro de la regla para las notificaciones contenidas en el conjunto de notificaciones de entrada (las notificaciones que coinciden con la condición de la regla se conocen como notificaciones coincidentes). Si no se encuentran notificaciones coincidentes, el motor de notificaciones ejecuta la instrucción de emisión de la regla para cada conjunto de las notificaciones coincidentes. La instrucción de emisión de la regla puede realizar cualquiera de las siguientes tareas con notificaciones coincidentes:

1. Copiar una notificación coincidente en el conjunto de notificaciones de salida.

2. Transformar los campos de notificación y crear una nueva notificación o bien solo en el conjunto de notificaciones de entrada, o bien en los conjuntos de notificaciones de salida y de evaluación.

3. Use las notificaciones coincidentes como una clave para buscar más información de un almacén de atributos para crear reclamaciones nuevas, bien solo en el conjunto de notificaciones de entrada, o bien en los conjuntos de notificaciones de salida y de evaluación.

Adición de una notificación al conjunto de notificaciones de salida para un conjunto de reglas

El conjunto de notificaciones de salida es una ubicación de memoria que inicialmente está vacía y tiene una gran importancia, ya que el motor de notificaciones solo devolverá notificaciones que residan en el conjunto de notificaciones de salida cuando finalice el proceso de ejecución. Esto significa que las notificaciones que residan únicamente en el conjunto de notificaciones de entrada y no en el conjunto de notificaciones de salida se omitirán cuando llegue el momento de calcular el conjunto final de notificaciones salientes.

Adición de una notificación a ambos conjuntos de notificaciones para un conjunto de reglas

A medida que se procesa una regla, las notificaciones se agregan solo al conjunto de notificaciones de entrada, o tanto al de entrada como al de salida, en función de la instrucción que se use en la instrucción de emisión de la regla. El lenguaje de reglas de notificación se refiere a estas instrucciones como add o issue.

Si se usa la instrucción add, las notificaciones se agregan solo al conjunto de notificaciones de entrada y dichas notificaciones existirán únicamente para los fines de la ejecución y dejarán de existir una vez finalice la misma. Si se usa la instrucción issue, las notificaciones se agregan tanto al conjunto de notificaciones de entrada como al de salida y se devuelven en el conjunto de notificaciones de salida cuando finalice la ejecución. Para más información sobre estas instrucciones, consulte The Role of the Claim Rule Language.

Si la parte de la condición de una regla dentro de un conjunto de reglas no coincide con ninguna notificación del conjunto de notificaciones de entrada, la parte de la instrucción de emisión de la regla se omite y, por tanto, no se agrega ninguna notificación al conjunto de notificaciones de salida ni al de entrada. En la siguiente ilustración y sus pasos correspondientes se muestra lo que sucede cuando el motor de notificaciones ejecuta una regla de transformación:

1. El motor de notificaciones agrega las notificaciones entrantes al conjunto de notificaciones de entrada.

2. Cuando se ejecuta la primera regla, ve las notificaciones A y B, que en ese momento son las únicas notificaciones en el conjunto de notificaciones de entrada, y procesa la parte condicional de la lógica de la regla 1.

3. Puesto que la notificación A está presente en el conjunto de notificaciones de entrada, la condición de la regla se determina como verdadera (coincidente con la notificación A) y se agrega una nueva notificación C tanto al conjunto de notificaciones de entrada como al conjunto de notificaciones de salida.

4. La regla 2 ahora puede usar las notificaciones A, B y C (todas las notificaciones del conjunto de notificaciones de entrada) como entrada para procesar su lógica.

Para más información sobre la transformación de notificaciones, consulte When to Use a Transform Claim Rule.

Paso 3: resultado de la ejecución.

La fase final de la ejecución del conjunto de reglas de notificación comienza cuando se han ejecutado todas las reglas dentro de un conjunto de reglas determinado y el conjunto final de notificaciones está presente en el conjunto de notificaciones de salida. En ese momento, el motor de notificaciones devuelve el contexto del conjunto de notificaciones de salida como el resultado de la ejecución del conjunto de reglas. A partir de ese punto, es la canalización de notificaciones la que asume y mueve este resultado final a la siguiente fase en su proceso.

Envío del resultado de la ejecución a la canalización de notificaciones

Cuando el motor de notificaciones procesa un conjunto de reglas, dicho conjunto de reglas tiene sus propias ubicaciones dedicadas en memoria para sus conjuntos de notificaciones de entrada y salida. Esto significa que los conjuntos de notificaciones de entrada y salida que usa un conjunto de reglas son independientes de los conjuntos de entrada y salida que se utilizan en otro conjunto de reglas.

Después de que todo el proceso se haya ejecutado para un conjunto de reglas determinado (pasos 1, 2 y 3), las notificaciones salientes recién emitidas (el contenido del conjunto de notificaciones de salida) se usarán como entrada para el siguiente conjunto de reglas de la canalización de notificaciones. Esto permite que las notificaciones fluyan desde la salida de un conjunto de reglas a la entrada de otro, tal y como se muestra en la ilustración siguiente.

Nota:

Aunque el conjunto de reglas de emisión también es una fase crítica de la canalización, en la ilustración anterior no se muestra únicamente por motivos de simplificación. Para ver una ilustración en la que se muestra el conjunto de reglas de emisión y cómo encaja en la canalización de notificaciones, consulte The Role of the Claims Pipeline.

En este caso, la canalización usa la salida de las reglas de aceptación para llevar el conjunto final de notificaciones producidas por las reglas de aceptación a la segunda fase de la canalización, que es el procesamiento de las reglas de autorización. En este punto, el proceso de ejecución de reglas de notificación completo (los pasos 1, 2 y 3 anteriores) se ejecutaría de nuevo para el conjunto de reglas de autorización. Este ciclo continúa hasta que se complete el conjunto de reglas de emisión (la fase final de la canalización).

Cuando las notificaciones salientes finalizadas se hayan devuelto desde el motor para el conjunto de reglas de emisión, se empaquetarán en un token SAML y el Servicio de federación enviará el token de vuelta al cliente.

Procesamiento de las reglas de autorización

Si el conjunto de reglas de notificación que se ejecuta durante el paso 2 del proceso de ejecución de reglas de notificación consta de reglas de autorización (que tienen conjuntos de notificaciones de entrada y salida diferentes a los de las reglas de aceptación o emisión), se ejecutarán las reglas de autorización para determinar si el solicitante de un token está autorizado para obtener un token de seguridad para un determinado usuario autenticado del Servicio de federación basado en las notificaciones del solicitante.

El objetivo de las reglas de autorización es emitir una notificación de denegación o de permiso, según si el usuario está habilitado o no para obtener un token para el usuario autenticado proporcionado. Como se muestra en la ilustración siguiente, la canalización utiliza el resultado de la ejecución de autorización para determinar si se ejecuta o no el conjunto de reglas de emisión (según la presencia o ausencia de la notificación de denegación o de permiso), pero el resultado de la ejecución de autorización en sí misma no se usa como entrada para el conjunto de reglas de notificación.

Para más información sobre la autorización de notificaciones, consulte When to Use an Authorization Claim Rule.