Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # 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](fgac.md). En lugar de autenticarse a través de [Amazon](cognito-auth.md) Cognito o [la base de datos de usuarios interna](fgac.md#fgac-dashboards), 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, Active Directory Federation Services (ADFS), Auth0 y. AWS IAM Identity Center La autenticación SAML para los paneles 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 los paneles de control. OpenSearch APIs ## 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 tu proveedor exacto, solo para tu dominio de OpenSearch servicio. El flujo de inicio de sesión en OpenSearch Dashboards puede adoptar una de estas dos formas: + **Proveedor de servicios (SP) iniciado**: navegue al panel (por ejemplo, `https://my-domain.us-east-1.es.amazonaws.com/_dashboards`), que lo redirige a la pantalla de inicio de sesión. Después de iniciar sesión, el proveedor de identidades lo redirige al panel. + **Iniciado por el proveedor de identidad (IdP)**: navega hasta su proveedor de identidad, inicia sesión y elige OpenSearch Dashboards en un directorio de aplicaciones. OpenSearch El servicio ofrece dos inicios de sesión únicos URLs, uno iniciado por SP y otro iniciado por IdP, pero solo necesitará el que coincida con el flujo de inicio de sesión deseado en los paneles de control. 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](fgac.md#fgac-concepts) (opcional, pero recomendado). Esta información permite el [control de acceso detallado](fgac.md) 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: + Debido al tamaño del archivo de metadatos del IdP, se recomienda utilizar la consola de AWS para configurar la autenticación SAML. + Los dominios solo admiten un método de autenticación del panel a la vez. Si tiene habilitada la [autenticación de Amazon Cognito para OpenSearch paneles](cognito-auth.md), debe deshabilitarla antes de poder habilitar la autenticación SAML. + Si utiliza un equilibrador de carga de red con SAML, primero debe crear un punto de conexión personalizado. Para obtener más información, consulte [Crear un punto de conexión personalizado para Amazon OpenSearch Service](customendpoint.md). + Las políticas de control de servicios (SCP) no se aplicarán ni evaluarán en el caso de identidades que no sean de IAM (como SAML en OpenSearch Amazon Serverless y SAML y la autorización básica de usuario interna para Amazon Service). OpenSearch ## 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](https://developer.okta.com/docs/concepts/saml/#planning-for-saml). ## 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](ac.md#ac-types-resource), que proporciona acceso completo a los subrecursos (`/*`) en el dominio: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` ------ 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 subred 192.0.2.0/24: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*" } ] } ``` ------ **nota** Una política de acceso a un dominio abierto requiere que se habilite un control de acceso detallado en el dominio; de lo contrario, aparece el siguiente error: `To protect domains with public access, a restrictive policy or fine-grained access control is required.` Si tiene un usuario maestro o un usuario interno configurado con una contraseña segura, mantener la política abierta mientras usa un control de acceso detallado podría ser aceptable desde el punto de vista de la seguridad. Para obtener más información, consulte [Control de acceso detallado en Amazon Service OpenSearch](fgac.md). ## Configuración de la autenticación iniciada por proveedor de servicios o por proveedor de identidades En estos pasos se explica cómo habilitar la autenticación SAML con la autenticación iniciada por el SP *o* por el IdP para los paneles de control. OpenSearch Para conocer el paso adicional necesario para habilitar ambas, consulte [Configuración de la autenticación iniciada por proveedor de servicios o por proveedor de identidades](#saml-idp-with-sp). ### 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 identificador de entidad o un SSO del proveedor de servicios. URLs 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 utilizas un [punto final personalizado](customendpoint.md), puedes deducir cuál URLs será. Por ejemplo, si el punto de conexión personalizado es `www.custom-endpoint.com`, el ID de entidad del proveedor de servicios será`www.custom-endpoint.com`, la URL de SSO iniciado por IdP será `www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated`, y la URL de SSO iniciado por SP 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. **nota** No puede iniciar sesión con un punto de conexión de doble pila porque el FQDN de una solicitud HTTP es diferente del FQDN de una solicitud SAML. Un OpenSearch administrador tendrá que configurar un punto final personalizado y establecer el valor de CNAME en un punto final de doble pila si quieres iniciar sesión con un punto final de doble pila. 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. Después, cuando el dominio esté activo, podrás recuperar los valores correctos de OpenSearch Service y actualizarlos en Okta. Para obtener instrucciones, consulte [Paso 6: Actualiza tu IdP URLs](#saml-update-urls). #### Si va a editar un dominio existente Si habilitas la autenticación SAML en un dominio existente, copia el ID de la entidad del proveedor de servicios y uno de los SSO. URLs Para obtener orientación sobre qué URL debe utilizar, consulte [Información general de la configuración de SAML](#saml-overview). ![\[Service provider entity ID and SSO URLs for SAML authentication configuration.\]](http://docs.aws.amazon.com/es_es/opensearch-service/latest/developerguide/images/SAML.png) 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](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html): `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: ``` tls-certificate urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ``` ### 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: + **ID de entidad del IdP**: copie el valor de la propiedad `entityID` del archivo de metadatos y péguelo en este campo. Muchos proveedores de identidades también muestran este valor como parte de un resumen posterior a la configuración. Algunos proveedores lo llaman el “emisor”. + Nombre de **usuario maestro** de **SAML y función de backend maestro de SAML: la función** de and/or backend de usuario que especifique recibe todos los permisos para el clúster, lo que equivale a un [nuevo usuario maestro](fgac.md#fgac-more-masters), pero solo puede usar esos permisos en los paneles. OpenSearch Por ejemplo, en Okta, es posible que tenga un usuario `jdoe` que pertenece al grupo `admins`. Si agrega `jdoe` al **nombre de usuario maestro de SAML**, solo ese usuario recibe permisos completos. Si agrega `admins` Rol de backend maestro de SAML, cualquier usuario que pertenezca al grupo `admins` recibe permisos completos. **nota** El contenido de la aserción SAML debe coincidir exactamente con las cadenas que se utilicen para el nombre de usuario maestro de SAML y el rol maestro de SAML. Algunos proveedores de identidad añaden un prefijo antes de sus nombres de usuario, lo que puede provocar que no coincidan. hard-to-diagnose En la interfaz de usuario del proveedor de identidades, es posible que vea `jdoe`, pero la aserción SAML podría contener `auth0|jdoe`. Utilice siempre la cadena de la aserción SAML. Muchos proveedores de identidades permiten ver una aserción de muestra durante el proceso de configuración, y herramientas como [Rastreo SAML](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) pueden ayudarlo a examinar y solucionar problemas del contenido de las aserciones reales. Las aserciones se ven algo similar a lo siguiente: ``` idp-issuer username domain-endpoint urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport GroupName Match Matches regex ".+" (case-sensitive) ``` ### Paso 5: (opcional) configurar ajustes adicionales En **Configuración adicional**, configure los siguientes campos opcionales: + **Clave de asunto**: puede dejar este campo vacío con el fin de utilizar el elemento `NameID` de la aserción SAML para el nombre de usuario. Si su aserción no utiliza este elemento estándar y, en su lugar, incluye el nombre de usuario como un atributo personalizado, especifique ese atributo aquí. + **Clave de roles**: si desea utilizar roles de backend (se recomienda), especifique un atributo de la aserción en este campo; por ejemplo, `role` o `group`. Esta es otra situación en la que herramientas como [Rastreo SAML](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) pueden ayudar. + **Duración de la sesión: de forma predeterminada**, OpenSearch Dashboards cierra la sesión de los usuarios después de 24 horas. Puede establecer este valor en cualquier número comprendido entre 60 y 1440 (24 horas) especificando un nuevo valor. Cuando la configuración le parezca adecuada, guarde el dominio. ### Paso 6: Actualiza tu IdP URLs Si [habilitaste la autenticación SAML al crear un dominio](#saml-configure-new), tenías que especificar un valor temporal URLs en tu IdP para poder generar el archivo de metadatos XML. Una vez que el estado del dominio cambie a`Active`, podrás obtener el URLs IdP correcto y modificarlo. Para recuperarlo URLs, selecciona el dominio y elige **Acciones**, **editar la configuración de seguridad**. En la sección **Autenticación SAML para OpenSearch Dashboards/Kibana**, encontrarás el identificador de entidad del proveedor de servicios y el SSO correctos. URLs Copia los valores y úsalos para configurar tu proveedor de identidad, sustituyendo el temporal URLs que proporcionaste 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. + Si eligió la dirección URL iniciada por el SP, diríjase a `domain-endpoint/_dashboards`. Para iniciar sesión directamente en un inquilino específico, puede agregar `?security_tenant=tenant-name` a la URL. + Si eligió la dirección URL iniciada por el IdP, diríjase al directorio de aplicaciones de su proveedor de identidad. 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 cargue OpenSearch el panel de mandos, selecciona **Seguridad** y roles.** A continuación, [asigne los roles](fgac.md#fgac-mapping) 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 de la autenticación iniciada por proveedor de servicios y por proveedor de identidades Si desea configurar la autenticación iniciada por SP e IdP, debe hacerlo a través de su proveedor de identidades. Por ejemplo, en Okta, puede seguir estos pasos: 1. Dentro de su aplicación SAML, vaya a **General**, **Configuración SAML**. 1. Para la **URL de inicio de sesión único**, proporcione URL SSO iniciado por *IdP*. Por ejemplo, `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated`. 1. Activa **Permitir que esta aplicación solicite otro URLs SSO**. 1. En SSO **solicitable URLs, agrega uno o más SSO** iniciados por el *SP.* URLs Por ejemplo, `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs`. ## Configuración de 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 `\n` en lugar de `` 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](https://docs.aws.amazon.com/cli/latest/reference/). ## 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 `\n` en lugar de `` 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](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_Welcome.html). ## Solución de problemas de SAML | Error | Details | | --- | --- | | Tu solicitud: '*/some/path*' no está permitida. | Compruebe que ha proporcionado la dirección [URL de SSO](#saml-enable) correcta (paso 3) a su proveedor de identidad. | | Proporcione un documento de metadatos del proveedor de identidad válido para habilitar SAML. | El archivo de metadatos del IdP no cumple con el estándar SAML 2.0. Verifique si hay errores mediante una herramienta de validación. | | Las opciones de configuración de SAML no son visibles en la consola. | Actualice a la versión más reciente del [software de servicio](service-software.md). | | Error de configuración de SAML: se produjo un error al recuperar la configuración de SAML. Verifique su configuración. | Este error genérico puede producirse por muchas razones. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/opensearch-service/latest/developerguide/saml.html) | | Rol faltante: no hay roles disponibles para este usuario. Póngase en contacto con el administrador del sistema. | Se ha autenticado correctamente, pero el nombre de usuario y los roles de backend de la aserción SAML no se asignan a ningún rol y, por lo tanto, no tienen permisos. Estos mapeos distinguen entre mayúsculas y minúsculas. El administrador del sistema puede verificar el contenido de su aserción SAML con una herramienta como [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) y comprobar la asignación de roles con la siguiente solicitud: 
GET _plugins/_security/api/rolesmapping
| | Su navegador redirige o recibe continuamente errores HTTP 500 al intentar acceder OpenSearch a los paneles. | Estos errores pueden producirse si la aserción SAML contiene un gran número de roles con un total aproximado de 1500 caracteres. Por ejemplo, si transfiere 80 roles, cuya longitud media es de 20 caracteres, es posible que supere el límite de tamaño de las cookies en su navegador web. A partir de OpenSearch la versión 2.7, la aserción SAML admite funciones de hasta 5000 caracteres. | | No puede cerrar sesión en ADFS. | ADFS requiere que todas las solicitudes de cierre de sesión estén firmadas, algo que el OpenSearch servicio no admite. Elimine `` del archivo de metadatos del IdP para obligar al OpenSearch Servicio a utilizar su propio mecanismo de cierre de sesión interno. | | `Could not find entity descriptor for __PATH__.` | El ID de entidad del IdP proporcionado en el XML de metadatos al OpenSearch servicio es diferente al de la respuesta de SAML. Para ello, asegúrese de que coincidan. Active los **registros de errores de aplicaciones de CW** en su dominio para encontrar el mensaje de error y depurar el problema de integración con SAML. | | `Signature validation failed. SAML response rejected.` | OpenSearch El servicio no puede verificar la firma de la respuesta de SAML mediante el certificado del IdP proporcionado en el XML de metadatos. Puede deberse a un error manual o a que su IdP haya rotado su certificado. Actualice el certificado más reciente de su IdP en el XML de metadatos proporcionado al OpenSearch Servicio a través del. Consola de administración de AWS | | `__PATH__ is not a valid audience for this response.` | El campo de audiencia de la respuesta de SAML no coincide con el punto de conexión del dominio. Para corregir este error, actualice el campo de audiencia del SP para que coincida con el punto de conexión de su dominio. Si ha activado los puntos de conexión personalizados, el campo de audiencia debe coincidir con su punto de conexión personalizado. Active los **registros de errores de aplicaciones de CW** en su dominio para encontrar el mensaje de error y depurar el problema de integración con SAML. | | Su navegador recibe un mensaje de error HTTP 400 con `Invalid Request Id` en la respuesta. | Este error suele producirse si ha configurado la URL iniciada por el IdP con este formato `/_opendistro/_security/saml/acs`. En su lugar, configure la URL con el formato `/_opendistro/_security/saml/acs/idpinitiated`. | | La respuesta se recibió en `__PATH__` en vez de `__PATH__`. | El campo de destino de la respuesta SAML no coincide con ninguno de los siguientes formatos de URL: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/opensearch-service/latest/developerguide/saml.html) Según el flujo de inicio de sesión que utilice (iniciado por SP o iniciado por IDP), introduzca un campo de destino que coincida con uno de los. OpenSearch URLs | | La respuesta tiene un atributo `InResponseTo`, pero no se esperaba `InResponseTo`. | Está utilizando la URL iniciada por IdP para un flujo de inicio de sesión iniciado por SP. En su lugar, utilice la URL iniciada por SP. | ## Deshabilitar la autenticación SAML **Para deshabilitar la autenticación SAML en los paneles de control (consola) OpenSearch** 1. Seleccione el dominio, **Acciones** y **Editar la configuración de seguridad**. 1. Desmarque **Habilitar la autenticación SAML**. 1. Seleccione **Guardar cambios**. 1. Después de que el dominio termine de procesar, compruebe el mapeo de roles de control de acceso detallado con la siguiente solicitud: ``` GET _plugins/_security/api/rolesmapping ``` Al deshabilitar la autenticación SAML para los paneles de control, *no* se eliminan las asignaciones del nombre de usuario maestro de SAML, la función de backend del maestro de SAML. and/or Si desea eliminar estos mapeos, inicie sesión en Dashboards con la base de datos de usuario interna (si está habilitada) o utilice la API para eliminarlos: ``` PUT _plugins/_security/api/rolesmapping/all_access { "users": [ "master-user" ] } ```