Identity Providers y Jerarquía Organizacional
Por Qué el Identity Provider es Fundamental
Apono no gestiona usuarios y contraseñas directamente. Depende de un Identity Provider (IdP) como fuente de verdad para saber:
- Quiénes son los usuarios de la organización.
- A qué grupos pertenece cada usuario (ej: backend-team, infra-team, security-team).
- Quién es el gestor de cada persona — información esencial para flujos de aprobación.
Sin esta integración, Apono no puede determinar automáticamente quién debe aprobar una solicitud de acceso cuando la regla es "aprobación del gestor directo". Es el Identity Provider el que proporciona esa jerarquía.
Si la organización aún no tiene la jerarquía de gestores configurada en el Identity Provider, Apono puede utilizarse normalmente. Una estrategia común de adopción es comenzar con un único equipo (como el equipo de seguridad o infraestructura) aprobando todas las solicitudes de acceso. Con el tiempo, conforme la organización gana madurez y configura la jerarquía en el Identity Provider, las aprobaciones pueden delegarse gradualmente a los gestores directos y líderes de cada equipo. Este enfoque permite adoptar Apono rápidamente sin depender de una estructura organizacional completa desde el primer día.
Proveedores Soportados
Apono soporta los principales proveedores de identidad del mercado:
| Proveedor | Protocolos | Sincronización |
|---|---|---|
| Microsoft Entra ID (Azure AD) | SAML, OIDC, SCIM | Usuarios, grupos y jerarquía de gestores |
| Okta | SAML, OIDC, SCIM | Usuarios, grupos y jerarquía de gestores |
| Google Workspace | OIDC, SCIM | Usuarios y grupos |
| OneLogin | SAML, OIDC | Usuarios y grupos |
La sincronización ocurre de forma continua — cuando un usuario es agregado, eliminado o movido de grupo en el Identity Provider, Apono refleja automáticamente estos cambios.
Configurando la Jerarquía de Gestores en Entra ID
Microsoft Entra ID (antiguo Azure AD) es uno de los proveedores más utilizados en ambientes corporativos. Para que Apono pueda identificar automáticamente quién es el gestor de cada persona, el campo Manager necesita estar completado en el perfil de cada usuario.
Cómo Funciona el Campo Manager
En Entra ID, cada usuario tiene un atributo llamado Manager que apunta a otro usuario — su gestor directo. Esta relación crea una cadena jerárquica que Apono consulta cuando un Access Flow exige "aprobación del gestor directo".
En este ejemplo, si Pedro Oliveira solicita acceso a un recurso con aprobación del gestor directo, Apono automáticamente envía la solicitud a Ana Costa (su gestora en Entra ID).
Configurando el Manager por el Portal de Azure
Para definir el gestor de un usuario en Entra ID:
- Acceda al Microsoft Entra admin center (entra.microsoft.com).
- Navegue hasta Identity → Users → All users.
- Seleccione el usuario que desea configurar.
- En la sección Properties, haga clic en Edit properties.
- En la pestaña Job information, localice el campo Manager.
- Haga clic en Change manager y seleccione el gestor correcto.
- Guarde los cambios.
Configurando el Manager vía Microsoft Graph API
Para organizaciones con muchos usuarios, configurar el gestor manualmente por el portal no es viable. La Microsoft Graph API permite automatizar esta configuración:
# Definir el gestor de un usuario vía Graph API
# Sustituya {user-id} por el ID del usuario
# Sustituya {manager-id} por el ID del gestor
curl -X PUT \
"https://graph.microsoft.com/v1.0/users/{user-id}/manager/\$ref" \
-H "Authorization: Bearer {access-token}" \
-H "Content-Type: application/json" \
-d '{
"@odata.id": "https://graph.microsoft.com/v1.0/users/{manager-id}"
}'
# Definir el gestor vía PowerShell con módulo Microsoft Graph
# Instalar: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.ReadWrite.All"
# Definir el gestor del usuario
$managerRef = @{
"@odata.id" = "https://graph.microsoft.com/v1.0/users/{manager-id}"
}
Set-MgUserManagerByRef -UserId "{user-id}" -BodyParameter $managerRef
Configurando la Jerarquía en Okta
En Okta, la jerarquía de gestores funciona de forma similar:
- Acceda al Okta Admin Console.
- Navegue hasta Directory → People.
- Seleccione el usuario.
- En la sección Profile, edite el campo Manager o managerId.
- Informe el ID o email del gestor.
Okta también permite configurar el campo Manager automáticamente vía importación de sistemas de RR.HH. como Workday, BambooHR o SAP SuccessFactors — lo que garantiza que la jerarquía esté siempre actualizada.
Cómo Apono Utiliza la Jerarquía
Cuando Apono se conecta al Identity Provider, sincroniza no solo los usuarios y grupos, sino también la relación de gestión entre ellos. Como el campo Manager crea una cadena jerárquica (Pedro → Ana → Juan → María), Apono puede navegar por esa cadena y utilizar cualquier nivel de ella en los flujos de aprobación.
Esto permite configurar Access Flows con reglas como:
- Aprobación del gestor directo: Apono identifica automáticamente quién es el gestor del solicitante y envía la notificación de aprobación.
- Aprobación del gestor del gestor (manager's manager): Para accesos más sensibles, Apono sube un nivel en la cadena jerárquica y envía la aprobación al gestor del gestor. Esto es útil cuando el acceso impacta áreas más allá del alcance del líder directo.
- Aprobación en múltiples niveles jerárquicos: Es posible combinar ambos — primero el gestor directo aprueba, después el gestor del gestor aprueba. Ambos necesitan aprobar para que el acceso sea concedido.
- Aprobación por grupo: Apono sabe a qué grupos pertenece el usuario y puede dirigir la aprobación a los responsables de ese grupo.
Ejemplo: Escalación Jerárquica
Considerando la jerarquía a continuación:
Es posible configurar diferentes flujos dependiendo de la sensibilidad:
| Tipo de Acceso | Aprobador | Nivel Jerárquico |
|---|---|---|
| Read-only en staging | Ana Costa (gestor directo) | 1 nivel arriba |
| Write en producción | Ana Costa + Juan Santos | 1 y 2 niveles arriba |
| Admin en producción | Ana Costa + Juan Santos + Equipo de Seguridad | 1 y 2 niveles + grupo fijo |
El diagrama a continuación ilustra un flujo de aprobación con dos niveles jerárquicos — donde tanto el gestor directo como el gestor del gestor necesitan aprobar:
Esta capacidad de navegar por la cadena jerárquica es lo que hace que la integración con el Identity Provider sea tan importante — sin el campo Manager correctamente completado, Apono no puede resolver automáticamente quién es el gestor del gestor.
Buenas Prácticas
- Mantener la jerarquía actualizada: Cambios de equipo, promociones y desvinculaciones deben reflejarse inmediatamente en el Identity Provider. Si el campo Manager está desactualizado, las aprobaciones van a la persona incorrecta.
- Automatizar vía sistemas de RR.HH.: Siempre que sea posible, integrar el Identity Provider con el sistema de RR.HH. (Workday, BambooHR, SAP) para que los cambios organizacionales se sincronicen automáticamente.
- Definir un fallback: Configurar un aprobador predeterminado para casos donde el gestor directo no está definido o no está disponible. Sin esto, las solicitudes pueden quedar bloqueadas esperando aprobación.
- Validar la configuración: Antes de poner Apono en producción, verificar que todos los usuarios tengan el campo Manager correctamente completado. Los usuarios sin gestor definido no podrán usar flujos que dependan de esta información.
- Usar grupos para segmentación: Además de la jerarquía de gestores, organizar los usuarios en grupos que reflejen equipos y responsabilidades. Esto facilita la creación de Access Flows específicos por equipo.