Requisitos de seguridad de los mensajes accionables en Office 365

  • Artículo

Proteger los mensajes de correo electrónico accionables es fácil y sencillo. Existen dos fases dentro de la experiencia integral en las que es obligatorio cumplir una serie de requisitos de seguridad en el servicio cuando se admiten mensajes accionables con Office 365. Aquí veremos cuáles son esas fases y sus requisitos correspondientes.

  1. Fase de envío. Estos son los requisitos previos necesarios para que el servicio pueda enviar mensajes accionables:
    • Si usa correos electrónicos que requieren acción, tendrá que habilitar la verificación del remitente. Cabe mencionar que esto no tiene validez con los mensajes de conector.
    • El servicio debe estar registrado en Microsoft.
    • La dirección URL de acción debe admitir HTTPS.
  2. Fase de procesamiento de la acción. Cuando se procesa una acción, el servicio debe realizar lo siguiente:
    • Comprobar el token de portador (un token web de JSON) incluido en el encabezado de la solicitud HTTP POST. Esta comprobación también se puede realizar con las bibliotecas de ejemplo que Microsoft suministra.
    • Incluir un token de propósito limitado del servicio en la dirección URL de destino, que el servicio puede usar para establecer una relación entre la dirección URL del servicio y el usuario y la solicitud que nos ocupa. Esto es opcional, pero enormemente recomendable.

Verificación del remitente

Office 365 necesita la verificación del remitente para habilitar los mensajes que requieren acción por correo electrónico. Los correos electrónicos de mensajes que requieren acción tienen que originarse desde servidores que implementen DomainKeys Identified Mail (DKIM) y el marco de directivas de remitente (SPF), o bien necesita implementar tarjetas firmadas.

Aunque DKIM y SPF son suficientes para algunos escenarios, esa solución no funcionará en algunas situaciones donde los correos electrónicos se envían mediante un proveedor externo, lo que puede causar que los destinatarios no vean el mensaje que requiere acción mejorado. Por este motivo, le recomendamos que siempre implemente tarjetas firmadas que funcionen en todos los casos y que sean básicamente más seguras, ya que no dependen de registros DNS.

Implementar DKIM y SPF

DKIM y SPF son métodos estándar del sector que permiten demostrar la identidad de un remitente al enviar correos electrónicos mediante SMTP. Muchas compañías ya implementan estos estándares para proteger los correos electrónicos que envían. Para obtener más información sobre SPF y DKIM y cómo implementarlos, vea:

Cargas de trabajo de tarjetas firmadas

Los mensajes que requieren acción enviados por correo electrónico admiten un método de verificación alternativo: firmar la carga de la tarjeta con una clave RSA o un certificado X509. Este método es necesario en los escenarios siguientes:

  • Error de SPF y DKIM causado por la configuración del remitente o porque el entorno empresarial del destinatario estableció servicios de seguridad personalizados frente a los servicios de Office 365.
  • El escenario para mensajes que requieren acción necesita el envío desde varias cuentas de correo electrónico.

Para usar tarjetas firmadas, debe registrar la clave pública en el panel del programador de correo electrónico y usar la clave privada correspondiente para firmar la tarjeta.

SignedCard

Las tarjetas de mensajes que requieren acción firmadas están disponibles al enviar correos electrónicos. Use este formato para incluir una tarjeta firmada en el cuerpo HTML de un correo electrónico. Esta carga se serializa en el formato de microdatos adjunto al final del cuerpo HTML.

<section itemscope itemtype="http://schema.org/SignedAdaptiveCard">
    <meta itemprop="@context" content="http://schema.org/extensions" />
    <meta itemprop="@type" content="SignedAdaptiveCard" />
    <div itemprop="signedAdaptiveCard" style="mso-hide:all;display:none;max-height:0px;overflow:hidden;">[SignedCardPayload]</div>
</section>

Nota: Los Partners que prefieren usar la entidad MessageCard heredada pueden crear una entidad SignedMessageCard en lugar de un SignedAdaptiveCard.

SignedCardPayload

SignedCardPayload es una cadena codificada por el estándar JSON Web Signature (JWS). RFC7515 describe JWS y RFC7519 describe JSON Web Token (JWT). Dado que ninguna notificación es necesaria para JWT, las bibliotecas JWT pueden usarse para crear la firma JWS.

Nota: El término "JWT" puede usarse de manera intercambiable en la práctica. Pero, aquí preferimos el término "JWS".

Este es un ejemplo de SignedCardPayload. La tarjeta adaptable codificada aparecerá en forma de [encabezado].[carga].[firma] según la especificación JWS.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZW5kZXIiOiJzZXJ2aWNlLWFjY291bnRAY29udG9zby5jb20iLCJvcmlnaW5hdG9yIjoiNjVjNjgwZWYtMzZhNi00YTFiLWI4NGMtYTdiNWM2MTk4NzkyIiwicmVjaXBpZW50c1NlcmlhbGl6ZWQiOiJbXCJqb2huQGNvbnRvc28uY29tXCIsXCJqYW5lQGNvbnRvc28uY29tXCJdIiwiYWRhcHRpdmVDYXJkU2VyaWFsaXplZCI6IntcIiRzY2hlbWFcIjpcImh0dHA6Ly9hZGFwdGl2ZWNhcmRzLmlvL3NjaGVtYXMvYWRhcHRpdmUtY2FyZC5qc29uXCIsXCJ0eXBlXCI6XCJBZGFwdGl2ZUNhcmRcIixcInZlcnNpb25cIjpcIjEuMFwiLFwiYm9keVwiOlt7XCJzaXplXCI6XCJsYXJnZVwiLFwidGV4dFwiOlwiSGVsbG8gQWN0aW9uYWJsZSBtZXNzYWdlXCIsXCJ3cmFwXCI6dHJ1ZSxcInR5cGVcIjpcIlRleHRCbG9ja1wifV0sXCJhY3Rpb25zXCI6W3tcInR5cGVcIjpcIkFjdGlvbi5JbnZva2VBZGRJbkNvbW1hbmRcIixcInRpdGxlXCI6XCJPcGVuIEFjdGlvbmFibGUgTWVzc2FnZXMgRGVidWdnZXJcIixcImFkZEluSWRcIjpcIjNkMTQwOGY2LWFmYjMtNGJhZi1hYWNkLTU1Y2Q4NjdiYjBmYVwiLFwiZGVza3RvcENvbW1hbmRJZFwiOlwiYW1EZWJ1Z2dlck9wZW5QYW5lQnV0dG9uXCJ9XX0iLCJpYXQiOjE1NDUzNDgxNTN9.BP9mK33S1VZyjtWZd-lNTTjvueyeeoitygw9bl17TeQFTUDh9Kg5cB3fB7BeZYQs6IiWa1VGRdiiR4q9EkAB1qDsmIcJnw6aYwDUZ1KY4lNoYgQCH__FxEPHViGidNGtq1vAC6ODw0oIfaTUWTa5cF5MfiRBIhpQ530mbRNnA0QSrBYtyB54EDJxjBF1vNSKOeVHAl2d4gqcGxsytQA0PA7XMbrZ8B7fEU2uNjSiLQpoh6A1tevpla2C7W6h-Wekgsmjpw2YToAOX67VZ1TcS5oZAHmjv2RhqsfX5DlN-ZsTRErU4Hs5d92NY9ijJPDunSLyUFNCw7HLNPFqqPmZsw

El encabezado en JWS de arriba es:

{
  "alg": "RS256",
  "typ": "JWT"
}

La carga en JWS de arriba es:

{
  "sender": "service-account@contoso.com",
  "originator": "65c680ef-36a6-4a1b-b84c-a7b5c6198792",
  "recipientsSerialized": "[\"john@contoso.com\",\"jane@contoso.com\"]",
  "adaptiveCardSerialized": "{\"$schema\":\"http://adaptivecards.io/schemas/adaptive-card.json\",\"type\":\"AdaptiveCard\",\"version\":\"1.0\",\"body\":[{\"size\":\"large\",\"text\":\"Hello Actionable message\",\"wrap\":true,\"type\":\"TextBlock\"}],\"actions\":[{\"type\":\"Action.InvokeAddInCommand\",\"title\":\"Open Actionable Messages Debugger\",\"addInId\":\"3d1408f6-afb3-4baf-aacd-55cd867bb0fa\",\"desktopCommandId\":\"amDebuggerOpenPaneButton\"}]}",
  "iat": 1545348153
}
Notificaciones necesarias
Notificación Descripción
originator TIENE que establecerse como el id. proporcionado por Microsoft durante la incorporación.
iat La hora en que se firmó la carga.
sender La dirección de correo electrónico usada para enviar este mensaje que requiere acción.
recipientsSerialized La lista con formato de cadena de los destinatarios del correo electrónico. Esto debe incluir todo los destinatarios Para o CC del correo electrónico.
adaptiveCardSerialized La tarjeta adaptable con formato de cadena.

Código de ejemplo para generar una tarjeta firmada:

Comprobar que las solicitudes provengan de Microsoft

Todas las solicitudes de acción de Microsoft tienen un token de portador en el encabezado HTTP Authorization. Este token es un token web de JSON (JWT) firmado por Microsoft, e incluye notificaciones importantes que recomendamos encarecidamente que compruebe el servicio encargado de la solicitud asociada.

Nombre de la notificación Valor
aud Dirección URL base del servicio de destino, por ejemplo, https://api.contoso.com
iss El emisor del token. Debería ser https://substrate.office.com/sts/
sub Identidad del usuario que realizó la acción. En el caso de los mensajes accionables enviados por correo electrónico, sub sería la dirección de correo electrónico del usuario. En el caso de los conectores, sub será el objectID del usuario que realizó la acción.
sender Identidad del remitente del mensaje que contiene la acción. Este valor solo está presente si el mensaje se envío por correo electrónico. Los mensajes que requieren acción enviados a través de conectores no incluyen esta reclamación en su token de usuario.

Normalmente, las siguientes comprobaciones las suele efectuar un servicio.

  1. El token está firmado por Microsoft. Los metadatos de OpenID se encuentran en https://substrate.office.com/sts/common/.well-known/openid-configuration, lo que incluye información sobre las claves de firma.
  2. La notificación aud se corresponde con la dirección URL base del servicio.

Con todas las comprobaciones anteriores hechas, el servicio puede confiar en que las notificaciones sender y sub corresponden a la identidad del remitente y al usuario que realiza la acción. El servicio puede validar que las sender notificaciones y sub coinciden con el remitente y el usuario que espera.

Vea los siguientes ejemplos de código de Microsoft, en los que se indica cómo hacer estas comprobaciones en el token JWT.

Encabezado Action-Authorization

El uso del encabezado Authorization por los mensajes que requieren acción puede interferir con el mecanismo existente de autenticación o autorización del punto de conexión de destino. En este caso, los desarrolladores pueden establecer el Authorization encabezado en una cadena vacía en la headers propiedad de una Action.Http acción. Después, los mensajes que requieren acción enviarán el mismo token de portador con el encabezado Action-Authorization, en lugar de usar el encabezado Authorization.

Sugerencia

El servicio Azure Logic Apps devuelve HTTP 401 Unauthorized si el encabezado Authorization contiene el token de portador establecido por mensajes que requieren acción.

Ejemplo de Action.Http con el encabezado Action-Authorization

{
  "type": "Action.Http",
  "title": "Say hello",
  "method": "POST",
  "url": "https://api.contoso.com/sayhello",
  "body": "{{nameInput.value}}",
  "headers": [
    { "name": "Authorization", "value": "" }
  ]
}

Comprobar la identidad del usuario

El token de portador incluido en todas las solicitudes contiene la identidad de Azure AD del usuario de Office 365 que realizó la acción. Si es necesario, puede incluir su propio token específico del servicio en las URL de las acciones HTTP para representar la identidad del usuario en el sistema. Microsoft no dicta el modo en que el servicio debe diseñar o usar los tokens de propósito limitado. Este token es opaco a Microsoft, solamente se muestra al servicio.

Los tokens específicos para un servicio pueden usarse para poner en correlación las direcciones URL del servicio con usuarios y mensajes específicos. Microsoft le recomienda que, si usa su propio token específico para un servicio, lo incluya como parte de las URL de destino de acción, o bien en el cuerpo de la solicitud devuelta al servicio. Por ejemplo:

https://contoso.com/approve?requestId=abc&serviceToken=a1b2c3d4e5...

Los tokens específicos para un servicio actúan como id. de correlación (por ejemplo, un token con hash que usa userID, requestID y sal). Esto permite al proveedor de servicios llevar un seguimiento de las direcciones URL de acción que genera y envía, así como relacionarlas con las solicitudes de acción que se van produciendo. Además de usarse para la correlación, el proveedor de servicios puede usar el token específico para un servicio con el fin de protegerse ante ataques de reproducción. Por ejemplo, el proveedor de servicios puede rechazar una solicitud si la acción que contiene ya se realizó anteriormente con el mismo token.