Identity Providers e Hierarquia Organizacional
Por Que o Identity Provider é Fundamental
O Apono não gerencia usuários e senhas diretamente. Ele depende de um Identity Provider (IdP) como fonte de verdade para saber:
- Quem são os usuários da organização.
- A quais grupos cada usuário pertence (ex: backend-team, infra-team, security-team).
- Quem é o gestor de cada pessoa — informação essencial para fluxos de aprovação.
Sem essa integração, o Apono não consegue determinar automaticamente quem deve aprovar uma solicitação de acesso quando a regra é "aprovação do gestor direto". É o Identity Provider que fornece essa hierarquia.
Caso a organização ainda não tenha a hierarquia de gestores configurada no Identity Provider, o Apono ainda pode ser utilizado normalmente. Uma estratégia comum de adoção é começar com um único time (como o time de segurança ou infraestrutura) aprovando todas as solicitações de acesso. Com o tempo, conforme a organização ganha maturidade e configura a hierarquia no Identity Provider, as aprovações podem ser gradualmente delegadas para os gestores diretos e líderes de cada time. Essa abordagem permite adotar o Apono rapidamente sem depender de uma estrutura organizacional completa desde o primeiro dia.
Provedores Suportados
O Apono suporta os principais provedores de identidade do mercado:
| Provedor | Protocolos | Sincronização |
|---|---|---|
| Microsoft Entra ID (Azure AD) | SAML, OIDC, SCIM | Usuários, grupos e hierarquia de gestores |
| Okta | SAML, OIDC, SCIM | Usuários, grupos e hierarquia de gestores |
| Google Workspace | OIDC, SCIM | Usuários e grupos |
| OneLogin | SAML, OIDC | Usuários e grupos |
A sincronização acontece de forma contínua — quando um usuário é adicionado, removido ou movido de grupo no Identity Provider, o Apono reflete automaticamente essas mudanças.
Configurando a Hierarquia de Gestores no Entra ID
O Microsoft Entra ID (antigo Azure AD) é um dos provedores mais utilizados em ambientes corporativos. Para que o Apono consiga identificar automaticamente quem é o gestor de cada pessoa, o campo Manager precisa estar preenchido no perfil de cada usuário.
Como Funciona o Campo Manager
No Entra ID, cada usuário tem um atributo chamado Manager que aponta para outro usuário — seu gestor direto. Essa relação cria uma cadeia hierárquica que o Apono consulta quando um Access Flow exige "aprovação do gestor direto".
Nesse exemplo, se Pedro Oliveira solicitar acesso a um recurso com aprovação do gestor direto, o Apono automaticamente encaminha a solicitação para Ana Costa (sua gestora no Entra ID).
Configurando o Manager pelo Portal do Azure
Para definir o gestor de um usuário no Entra ID:
- Acesse o Microsoft Entra admin center (entra.microsoft.com).
- Navegue até Identity → Users → All users.
- Selecione o usuário que deseja configurar.
- Na seção Properties, clique em Edit properties.
- Na aba Job information, localize o campo Manager.
- Clique em Change manager e selecione o gestor correto.
- Salve as alterações.
Configurando o Manager via Microsoft Graph API
Para organizações com muitos usuários, configurar o gestor manualmente pelo portal não é viável. A Microsoft Graph API permite automatizar essa configuração:
# Definir o gestor de um usuário via Graph API
# Substitua {user-id} pelo ID do usuário
# Substitua {manager-id} pelo ID do 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 o gestor via PowerShell com módulo Microsoft Graph
# Instalar: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.ReadWrite.All"
# Definir o gestor do usuário
$managerRef = @{
"@odata.id" = "https://graph.microsoft.com/v1.0/users/{manager-id}"
}
Set-MgUserManagerByRef -UserId "{user-id}" -BodyParameter $managerRef
Configurando Hierarquia no Okta
No Okta, a hierarquia de gestores funciona de forma semelhante:
- Acesse o Okta Admin Console.
- Navegue até Directory → People.
- Selecione o usuário.
- Na seção Profile, edite o campo Manager ou managerId.
- Informe o ID ou e-mail do gestor.
O Okta também permite configurar o campo Manager automaticamente via importação de HR systems como Workday, BambooHR ou SAP SuccessFactors — o que garante que a hierarquia esteja sempre atualizada.
Como o Apono Utiliza a Hierarquia
Quando o Apono se conecta ao Identity Provider, ele sincroniza não apenas os usuários e grupos, mas também a relação de gestão entre eles. Como o campo Manager cria uma cadeia hierárquica (Pedro → Ana → João → Maria), o Apono consegue navegar por essa cadeia e utilizar qualquer nível dela nos fluxos de aprovação.
Isso permite configurar Access Flows com regras como:
- Aprovação do gestor direto: O Apono identifica automaticamente quem é o gestor do solicitante e envia a notificação de aprovação.
- Aprovação do gestor do gestor (manager's manager): Para acessos mais sensíveis, o Apono sobe um nível na cadeia hierárquica e envia a aprovação para o gestor do gestor. Isso é útil quando o acesso impacta áreas além do escopo do líder direto.
- Aprovação em múltiplos níveis hierárquicos: É possível combinar os dois — primeiro o gestor direto aprova, depois o gestor do gestor aprova. Ambos precisam aprovar para o acesso ser concedido.
- Aprovação por grupo: O Apono sabe a quais grupos o usuário pertence e pode direcionar a aprovação para os responsáveis daquele grupo.
Exemplo: Escalação Hierárquica
Considerando a hierarquia abaixo:
É possível configurar diferentes fluxos dependendo da sensibilidade:
| Tipo de Acesso | Aprovador | Nível Hierárquico |
|---|---|---|
| Read-only em staging | Ana Costa (gestor direto) | 1 nível acima |
| Write em produção | Ana Costa + João Santos | 1 e 2 níveis acima |
| Admin em produção | Ana Costa + João Santos + Time de Segurança | 1 e 2 níveis + grupo fixo |
O diagrama abaixo ilustra um fluxo de aprovação com dois níveis hierárquicos — onde tanto o gestor direto quanto o gestor do gestor precisam aprovar:
Essa capacidade de navegar pela cadeia hierárquica é o que torna a integração com o Identity Provider tão importante — sem o campo Manager preenchido corretamente, o Apono não consegue resolver automaticamente quem é o gestor do gestor.
Boas Práticas
- Mantenha a hierarquia atualizada: Mudanças de time, promoções e desligamentos devem refletir imediatamente no Identity Provider. Se o campo Manager estiver desatualizado, as aprovações vão para a pessoa errada.
- Automatize via HR systems: Sempre que possível, integre o Identity Provider com o sistema de RH (Workday, BambooHR, SAP) para que mudanças organizacionais sejam sincronizadas automaticamente.
- Defina um fallback: Configure um aprovador padrão para casos onde o gestor direto não está definido ou está indisponível. Sem isso, solicitações podem ficar travadas aguardando aprovação.
- Valide a configuração: Antes de colocar o Apono em produção, verifique se todos os usuários têm o campo Manager preenchido corretamente. Usuários sem gestor definido não poderão usar fluxos que dependem dessa informação.
- Use grupos para segmentação: Além da hierarquia de gestores, organize os usuários em grupos que reflitam times e responsabilidades. Isso facilita a criação de Access Flows específicos por equipe.