# SAML

> Activa el SSO para Applivery usando SAML 2.0 — integra con Okta, Azure AD, Ping Identity y más, con mapeo de atributos y grupos.

Source: https://docs.applivery.com/es/platform/authentication/sso/saml/  •  Last updated: 2026-06-08

**Answers:** ¿Qué es el SAML SSO y cómo funciona con Applivery? · ¿Qué proveedores de identidad admite Applivery para el SAML SSO? · ¿Qué portales de Applivery pueden usar el SAML SSO? · ¿Cómo funciona el mapeo de atributos en Applivery? · ¿Cómo funciona el mapeo de grupos y roles en el SAML SSO de Applivery?

**Key topics:** Configuración del SAML SSO, Integración con el proveedor de identidad, Mapeo de atributos, Mapeo de grupos, Mapeo de roles, Applivery, SAML 2.0, Okta, Azure AD, Ping Identity, Microsoft Entra ID, Auth0

---

**TL;DR:** Configura el SAML SSO para Applivery para habilitar la autenticación segura a través de tu proveedor de identidad existente, simplificando el acceso y la gestión de usuarios.

:::warning
Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/).
:::

SAML 2.0 (Security Assertion Markup Language) es el estándar de la industria para el Single Sign-On basado en web. Permite que tu proveedor de identidad (IdP) — como Okta, Azure AD o Ping Identity — gestione la autenticación, mientras que Applivery confía en el resultado y concede el acceso sin gestionar nunca las contraseñas de tus usuarios.

Una vez configurado, los usuarios que visitan un portal protegido de Applivery son redirigidos a la página de inicio de sesión de su IdP. Tras autenticarse allí, el IdP envía una aserción SAML firmada a Applivery confirmando la identidad y las membresías de grupos del usuario. Applivery valida la aserción y da acceso al usuario — sin necesidad de contraseña separada de Applivery.

El SAML SSO puede configurarse de forma independiente para cada uno de los tres portales de Applivery:

-   **Dashboard** — acceso para los Colaboradores (desarrolladores, administradores, viewers) que gestionan apps y políticas.
    
-   **Store Enterprise** — acceso para los empleados de la tienda que descargan Builds de apps internas.
    
-   **MDM Portal** — acceso para los usuarios de dispositivos que se autentican durante el enrollment o el acceso al portal.
    

* * *

## Proveedores de identidad compatibles

Applivery admite cualquier proveedor de identidad compatible con SAML 2.0. Hay guías de configuración paso a paso para los más comunes:

**Azure AD (Microsoft Entra ID)**

Incluye mapeo de grupos de seguridad y asignación de roles.

**Okta**

Incluye configuración de atributos de grupo y aprovisionamiento SCIM.

**Ping Identity**

Incluye mapeo de atributos e intercambio de metadatos de federación.

:::tip
Si tu IdP no está en la lista anterior, puedes configurar el SAML SSO siempre que sea compatible con SAML 2.0. El flujo general — intercambiar los metadatos del SP de Applivery, configurar el IdP, subir el XML de metadatos de federación del IdP a Applivery — es el mismo para todos los proveedores.
:::

* * *

## Flujo de autenticación

Cuando un usuario accede a un portal de Applivery protegido por SAML, el flujo funciona así:

El usuario visita tu dominio del Store Enterprise, el panel o el MDM Portal y hace clic en **Iniciar sesión**. Applivery lo redirige a la página de inicio de sesión de tu proveedor de identidad, donde se autentica con sus credenciales corporativas. Una vez autenticado, el IdP envía una respuesta SAML firmada al endpoint de callback de Applivery. Applivery valida la firma, extrae la identidad del usuario y la información de grupos de la aserción, y concede el acceso — mostrando solo las apps y recursos que el usuario está autorizado a ver.

* * *

## Mapeo de atributos

Applivery lee la identidad del usuario de atributos específicos de la aserción SAML. El nombre exacto del atributo varía según el proveedor de identidad. Puedes sobreescribir los valores predeterminados en la pantalla de configuración SAML bajo **Mapeo de atributos** — deja un campo en blanco para usar el valor predeterminado del IdP detectado.

### Correo electrónico

La dirección de correo es el identificador principal del usuario. Applivery lo busca en los siguientes lugares, en orden:

| IdP | Atributo |
| --- | --- |
| Estándar (predeterminado) | `nameID` |
| Azure AD | `EmailAddress` (`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`) |
| Auth0 | `http://schemas.auth0.com/email` |

### Nombre

| IdP | Atributo |
| --- | --- |
| Estándar (predeterminado) | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` |
| Azure AD | `http://schemas.microsoft.com/identity/claims/displayname` |
| Auth0 | `http://schemas.auth0.com/given_name` |

### Apellido

| IdP | Atributo |
| --- | --- |
| Estándar (predeterminado) | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` |
| Azure AD | `http://schemas.microsoft.com/identity/claims/displayname` |
| Auth0 | `http://schemas.auth0.com/family_name` |

### Grupos de usuarios

Los grupos de tu IdP se usan para el control de acceso en Applivery — controlando qué usuarios ven qué Publicaciones y asignando roles en el panel. Applivery lee los grupos de:

| IdP | Atributo |
| --- | --- |
| Estándar (predeterminado) | `http://schemas.xmlsoap.org/claims/Group` |
| Azure AD | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` |
| Okta | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` (configurado mediante Group Attribute Statement) |

* * *

## Mapeo de grupos

Algunos proveedores de identidad — especialmente Azure AD — no envían nombres de grupo en las aserciones SAML. En su lugar, envían identificadores opacos (Object IDs en el caso de Azure). La función de mapeo de grupos de Applivery permite traducir estos IDs a nombres de grupo legibles.

Puedes configurar mapeos clave/valor en tu configuración SAML en el [**panel de Applivery**](https://dashboard.applivery.io/), en Mapeo de grupos. Applivery también descubrirá automáticamente nuevos valores de grupo a medida que los usuarios se autentiquen y los añadirá a la lista — puedes asignarles nombres en cualquier momento sin necesidad de configurarlos todos por adelantado.

![group translation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/77dbb6fe-4d7d-443c-a18d-260855c5f24f.png)

Para una guía detallada específica de Azure AD, consulta [Single Sign-On con Azure AD — Mapeo de grupos de seguridad](https://docs.applivery.com/es/platform/authentication/sso/azure-ad/).

* * *

## Mapeo de roles desde SSO

Cuando SAML está configurado para el **panel**, Applivery puede asignar automáticamente un rol de Colaborador a los nuevos usuarios según los grupos enviados en su aserción SAML.

:::info
Esto aplica solo en el primer inicio de sesión — si el usuario ya existe en Applivery, su rol existente no cambia.
:::

El rol se determina según a cuál de los siguientes nombres de grupo reservados pertenece el usuario en su IdP:

| Nombre del grupo | Rol de Applivery asignado |
| --- | --- |
| `applivery-admin` | Admin |
| `applivery-editor` | Developer / Editor |
| `applivery-viewer` | Viewer |
| `applivery-unassigned` | Sin asignar |

Si un usuario pertenece a más de uno de estos grupos, el rol de mayor privilegio tiene prioridad. Si el usuario no pertenece a ninguno de estos grupos, se crea sin asignación de rol y un administrador tendrá que asignárselo manualmente.

:::tip
El mapeo de roles también funciona en combinación con el Mapeo de grupos. Si tu IdP envía Object IDs en lugar de nombres de visualización, puedes mapear los Object IDs a los nombres de grupo reservados (`applivery-admin`, etc.) en los ajustes de Mapeo de grupos, y la asignación de roles funcionará correctamente.
:::
:::info
El mapeo de roles solo aplica al modulo de **Distribución de Apps**. Los permisos de la Gestión de Dispositivos se rigen exclusivamente por los [permisos de segmentos](https://docs.applivery.com/es/device-management/general-settings/segments/).
:::