Autenticación SAML para paneles OpenSearch

La autenticación SAML para OpenSearch Dashboards te permite usar tu proveedor de identidad actual para ofrecer el inicio de sesión único (SSO) para los Dashboards de los dominios de Amazon OpenSearch Service que ejecuten OpenSearch Elasticsearch 6.7 o versiones posteriores. Para utilizar la autenticación SAML, debe habilitar el control de acceso detallado.

En lugar de autenticarse a través de Amazon Cognito o la base de datos de usuarios interna, la autenticación SAML OpenSearch para los paneles le permite utilizar proveedores de identidad de terceros para iniciar sesión en los paneles, administrar un control de acceso detallado, buscar sus datos y crear visualizaciones. OpenSearch El servicio es compatible con los proveedores que utilizan el estándar SAML 2.0, como Okta, Keycloak, Microsoft Entra ID, Active Directory Federation Services (ADFS), Auth0 y. AWS IAM Identity Center

La autenticación SAML para los paneles de control solo sirve para acceder a los paneles a través de un navegador web. OpenSearch Sus credenciales de SAML no le permiten realizar solicitudes HTTP directas a las API ni a las API de Dashboards. OpenSearch

Información general de la configuración de SAML

En esta documentación se supone que tiene un proveedor de identidad existente y que está familiarizado con él en cierta medida. No podemos proporcionar pasos de configuración detallados para su proveedor exacto, solo para su dominio de OpenSearch servicio.

El flujo de inicio de sesión en OpenSearch Dashboards puede adoptar una de estas dos formas:

OpenSearch El servicio proporciona dos URL de inicio de sesión único IdP-initiated, SP-initiated pero solo necesita la que coincida con el flujo de inicio de sesión deseado en Dashboards. OpenSearch

Independientemente del tipo de autenticación que utilice, el objetivo es iniciar sesión a través de su proveedor de identidades y recibir una aserción SAML que contenga su nombre de usuario (requerido) y cualquier rol backend (opcional, pero recomendado). Esta información permite el control de acceso detallado para asignar permisos a usuarios de SAML. En los proveedores de identidad externos, los roles backend se denominan generalmente “roles” o “grupos”.

Consideraciones

Tenga en cuenta lo siguiente cuando configure la autenticación SAML:

Autenticación SAML para dominios de VPC

SAML no requiere comunicación directa entre el proveedor de identidades y el proveedor de servicios. Por lo tanto, aunque tu OpenSearch dominio esté alojado en una VPC privada, puedes seguir usando SAML siempre que tu navegador pueda comunicarse con tu OpenSearch clúster y con tu proveedor de identidad. En esencia, el navegador actúa como intermediario entre el proveedor de identidades y el proveedor de servicios. Para ver un útil diagrama que explica el flujo de autenticación SAML, consulte la documentación de Okta.

Modificación de la política de acceso al dominio

Antes de configurar la autenticación SAML, debe actualizar la política de acceso al dominio para permitir a los usuarios de SAML acceder al dominio. De lo contrario, aparecerán errores de acceso denegado.

Recomendamos la siguiente política de acceso al dominio, que proporciona acceso completo a los subrecursos (/*) en el dominio:

Para hacer que la política sea más restrictiva, puede agregar una condición de dirección IP a la política. Esta condición limita el acceso únicamente a la subred o rango de direcciones IP especificados. Por ejemplo, la siguiente política solo permite el acceso desde la 192.0.2. 0/24subred:

Configuración de SP- o autenticación IdP-initiated

En estos pasos se explica cómo habilitar la autenticación SAML SP-initiated o la IdP-initiated autenticación para los OpenSearch paneles. Para conocer el paso adicional necesario para habilitar ambas, consulte Configurar tanto el SP como la autenticación. IdP-initiated

Paso 1: habilitar la autenticación SAML

Puede habilitar la autenticación SAML bien durante la creación del dominio o bien seleccionando Acciones, Editar la configuración de seguridad en un dominio existente. Los siguientes pasos varían ligeramente según lo que seleccione.

En la configuración del dominio, en Autenticación SAML para OpenSearch Dashboards/Kibana, selecciona Habilitar la autenticación SAML.

Paso 2: configurar el proveedor de identidades

Ejecute los siguientes pasos en función del momento de configuración de la autenticación SAML.

Si va a crear un nuevo dominio

Si estás creando un dominio nuevo, el OpenSearch servicio aún no puede generar un ID de entidad del proveedor de servicios ni una URL de inicio de sesión único. El proveedor de identidades requiere estos valores para habilitar correctamente la autenticación SAML, pero solo se pueden generar después de crear el dominio. Para evitar esta interdependencia durante la creación del dominio, puede proporcionar valores temporales en la configuración del IdP con el fin de generar los metadatos necesarios, y luego actualizarlos una vez que el dominio esté activo.

Si utiliza un punto de conexión personalizado, puede inferir cuáles serán las URL. Por ejemplo, si tu punto de enlace personalizado eswww.custom-endpoint.com, el ID de la entidad del proveedor de servicios seráwww.custom-endpoint.com, la URL del IdP-initiated SSO será www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated y la URL del SP-initiated SSO será. www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs Puede utilizar los valores para configurar el proveedor de identidades antes de crear el dominio. Consulte la siguiente sección para ver ejemplos.

Si no utiliza un punto de conexión personalizado, puede introducir valores temporales en el IdP para generar los metadatos necesarios, y luego actualizarlos una vez que el dominio esté activo.

Por ejemplo, en Okta puede introducir https://temp-endpoint.amazonaws.com en los campos URL de inicio de sesión único y URI de audiencia (ID de entidad del SP), lo que permite generar los metadatos. A continuación, cuando el dominio esté activo, podrás recuperar los valores correctos de OpenSearch Service y actualizarlos en Okta. Para obtener instrucciones, consulte Paso 6: Actualizar las URL del IdP.

Si va a editar un dominio existente

Si va habilitar la autenticación SAML en un dominio existente, copie el ID de entidad del proveedor de servicios y una de las URL de SSO. Para obtener orientación sobre qué URL debe utilizar, consulte Información general de la configuración de SAML.

Utilice los valores para configurar el proveedor de identidades. Esta es la parte más compleja del proceso, y, desafortunadamente, la terminología y los pasos varían enormemente según el proveedor. Consulte la documentación de su proveedor.

En Okta, por ejemplo, crea una aplicación web SAML 2.0. En URL de inicio de sesión único, especifique la URL de SSO. Para URI de audiencia (ID de identidad del SP), especifique el ID de entidad del SP.

En lugar de usuarios y roles de backend, Okta tiene usuarios y grupos. En Instrucciones de atributo de grupo, se recomienda agregar role al campo Nombre y la expresión regular .+ al campo Filtro. Esta instrucción indica al proveedor de identidades de Okta que incluya todos los grupos de usuarios bajo el campo role de la aserción SAML después de que un usuario se autentica.

En el Centro de identidades de IAM, especifique el ID de la entidad del SP como la audiencia de SAML de la aplicación. También debe especificar las siguientes asignaciones de atributos: Subject=${user:subject}:format=unspecified y Role=${user:groups}:format=uri.

En Auth0, crea una aplicación web regular y habilita el complemento SAML 2.0. En Keycloak, crea un cliente.

Paso 3: Importar metadatos del IdP

Después de configurar el proveedor de identidades, genera un archivo de metadatos de IdP. Este archivo XML contiene información sobre el proveedor, como un certificado TLS, puntos de conexión de inicio de sesión único y el ID de entidad del proveedor de identidad.

Copie el contenido del archivo de metadatos del IdP y péguelo en el campo Metadatos del IdP de la consola de servicio. OpenSearch Alternativamente, seleccione Importar desde archivo XML y cargue el archivo. El archivo de metadatos debe tener un aspecto similar al siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="entity-id" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>tls-certificate</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="idp-sso-url"/>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="idp-sso-url"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

Paso 4: configurar los campos SAML

Después de introducir los metadatos del IdP, configure los siguientes campos adicionales en la consola de OpenSearch servicio:

Muchos proveedores de identidad te permiten ver un ejemplo de aserción durante el proceso de configuración, y herramientas como estas SAML-tracerpueden ayudarte a examinar el contenido de las aserciones reales y solucionar los problemas que se encuentran en ellas. Las aserciones se ven algo similar a lo siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion ID="id67229299299259351343340162" IssueInstant="2020-09-22T22:03:08.633Z" Version="2.0"
  xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">idp-issuer</saml2:Issuer>
  <saml2:Subject>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData NotOnOrAfter="2020-09-22T22:08:08.816Z" Recipient="domain-endpoint/_dashboards/_opendistro/_security/saml/acs"/>
    </saml2:SubjectConfirmation>
  </saml2:Subject>
  <saml2:Conditions NotBefore="2020-09-22T21:58:08.816Z" NotOnOrAfter="2020-09-22T22:08:08.816Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>domain-endpoint</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>
  <saml2:AuthnStatement AuthnInstant="2020-09-22T19:54:37.274Z">
    <saml2:AuthnContext>
      <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
    </saml2:AuthnContext>
  </saml2:AuthnStatement>
  <saml2:AttributeStatement>
    <saml2:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
      <saml2:AttributeValue
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">GroupName Match Matches regex ".+" (case-sensitive)
      </saml2:AttributeValue>
    </saml2:Attribute>
  </saml2:AttributeStatement>
</saml2:Assertion>

Paso 5: (opcional) configurar ajustes adicionales

En Configuración adicional, configure los siguientes campos opcionales:

Cuando la configuración le parezca adecuada, guarde el dominio.

Paso 6: Actualizar las URL del IdP

Si ha habilitado la autenticación SAML mientras creaba un dominio, habrá tenido que especificar URL temporales para el IdP con el fin de generar el archivo de metadatos XML. Cuando el estado del dominio cambia a Active, puede obtener las URL correctas y modificar el IdP.

Para recuperar las URL, seleccione el dominio, y luego Acciones y Editar la configuración de seguridad. En la sección Autenticación SAML para OpenSearch Dashboards/Kibana, encontrará el ID de entidad del proveedor de servicios y las URL de SSO correctos. Copie los valores y utilícelos para configurar el proveedor de identidades, sustituyendo las URL temporales que proporcionó en el paso 2.

Paso 7: Asignar usuarios de SAML a roles

Una vez que el estado de su dominio sea Activo y su IDP esté configurado correctamente, navegue hasta los OpenSearch paneles.

En ambos casos, inicie sesión como usuario maestro SAML o como usuario que pertenece al rol de backend maestro SAML. Para continuar con el ejemplo del paso 7, inicie sesión como jdoe o un miembro del grupo admins.

Una vez que se OpenSearch cargue el panel de mandos, elija Seguridad, Funciones. A continuación, asigne los roles para permitir que otros usuarios accedan a los OpenSearch paneles.

Por ejemplo, podría asignar a su colega de confianza jroe a los roles all_access y security_manager. También puede asignar el rol de backend analysts a los roles readall y opensearch_dashboards_user.

Si prefiere usar la API en lugar de los OpenSearch paneles, consulte el siguiente ejemplo de solicitud:

PATCH _plugins/_security/api/rolesmapping
[
  {
    "op": "add", "path": "/security_manager", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] }
  },
  {
    "op": "add", "path": "/all_access", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] }
  },
  {
    "op": "add", "path": "/readall", "value": { "backend_roles": ["analysts"] }
  },
  {
    "op": "add", "path": "/opensearch_dashboards_user", "value": { "backend_roles": ["analysts"] }
  }
]

Configuración tanto del SP como de la autenticación IdP-initiated

Si desea configurar tanto el SP como la IdP-initiated autenticación, debe hacerlo a través de su proveedor de identidad. Por ejemplo, en Okta, puede seguir estos pasos:

Configurar la autenticación SAML (AWS CLI)

El siguiente AWS CLI comando habilita la autenticación SAML para los OpenSearch paneles de control de un dominio existente:

aws opensearch update-domain-config \
  --domain-name my-domain \
  --advanced-security-options '{"SAMLOptions":{"Enabled":true,"MasterUserName":"my-idp-user","MasterBackendRole":"my-idp-group-or-role","Idp":{"EntityId":"entity-id","MetadataContent":"metadata-content-with-quotes-escaped"},"RolesKey":"optional-roles-key","SessionTimeoutMinutes":180,"SubjectKey":"optional-subject-key"}}'

Debe escapar de todas las comillas y caracteres de nueva línea en el XML de metadatos. Por ejemplo, utilice <KeyDescriptor use=\"signing\">\n en lugar de <KeyDescriptor use="signing"> y un salto de línea. Para obtener información detallada sobre la utilización de la AWS CLI, consulte la Referencia de los comandos de la AWS CLI.

Configuración de la autenticación SAML (API de configuración)

La siguiente solicitud a la API de configuración habilita la autenticación SAML para los OpenSearch paneles de control de un dominio existente:

POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config
{
  "AdvancedSecurityOptions": {
    "SAMLOptions": {
      "Enabled": true,
      "MasterUserName": "my-idp-user",
      "MasterBackendRole": "my-idp-group-or-role",
      "Idp": {
        "EntityId": "entity-id",
        "MetadataContent": "metadata-content-with-quotes-escaped"
      },
      "RolesKey": "optional-roles-key",
      "SessionTimeoutMinutes": 180,
      "SubjectKey": "optional-subject-key"
    }
  }
}

Debe escapar de todas las comillas y caracteres de nueva línea en el XML de metadatos. Por ejemplo, utilice <KeyDescriptor use=\"signing\">\n en lugar de <KeyDescriptor use="signing"> y un salto de línea. Para obtener información detallada sobre el uso de la API de configuración, consulta la referencia de la API OpenSearch de servicio.

Solución de problemas de SAML

GET _plugins/_security/api/rolesmapping

Deshabilitar la autenticación SAML