Estrutura de acesso
A estrutura de acesso é usada para modelar acesso hierárquico num ambiente tanto para utilizadores internos como para utilizadores externos.
Uma estrutura de acesso pode representar clientes, departamentos, responsabilidades, funções ou agrupamentos de acesso de negócio semelhantes. Os utilizadores são atribuídos através de memberships a um nó na estrutura, e o acesso efetivo é resolvido durante o login.
Estrutura de acesso e nós
Cada estrutura de acesso contém uma única hierarquia de nós com exatamente um nó raiz.
Um nó contém:
- Um nome
- Opcionalmente claims que descrevem o acesso representado pelo nó
- Opcionalmente definições de política de acesso para utilizadores internos
- Opcionalmente nós filhos abaixo dele na hierarquia
A hierarquia pode ser usada para modelar acesso como:
- Cliente → Departamento → Função
- Organização → Equipa → Responsabilidade
- Parceiro → Região → Função
Exemplo: estrutura de acesso da Acme Corp
O exemplo seguinte modela acesso para o cliente Acme Corp com um departamento financeiro e uma função approver:
Acme Corp (customer=acme)
Finance (department=finance)
Approver (role=approver)
Nas definições da estrutura de acesso, o nó superior é Acme Corp com o claim customer=acme. O nó filho Finance acrescenta o claim department=finance, e o nó filho Approver acrescenta o claim role=approver e exige autenticação multifator (MFA).
Quando um utilizador é atribuído através de uma membership ao nó Approver, o FoxIDs resolve a hierarquia de Approver até Acme Corp.
Nas transformações de claims, os valores resolvidos ficam disponíveis como claims de acesso _local:.
Se Forward access structure claims to applications estiver ativado, os claims de acesso também são encaminhados para as transformações de claims e para as aplicações. Neste caso, os claims customer=acme, department=finance e role=approver.
Política de acesso de utilizadores internos
Os nós da estrutura de acesso podem aplicar uma política de início de sessão adicional a utilizadores internos. Estas definições não se aplicam a utilizadores externos.
Estão disponíveis as seguintes definições de nó:
- Grupo de política de palavra-passe
- Exigir autenticação multifator
- Desativar utilizadores internos
As definições aplicam-se a utilizadores com uma membership ativa no nó e a utilizadores com memberships ativas nos nós filhos abaixo dele. Por exemplo, se a MFA for exigida em Finance, também é exigida para um utilizador atribuído a Approver abaixo de Finance.
Se um utilizador tiver várias memberships ativas, FoxIDs combina todas as políticas de nó relevantes:
- Uma definição de desativação em qualquer nó relevante bloqueia o início de sessão, tal como se o próprio utilizador interno estivesse desativado.
- Um requisito MFA em qualquer nó relevante exige MFA, mesmo que o utilizador não exija MFA diretamente.
- Todos os grupos de política de palavra-passe relevantes são considerados juntamente com o grupo de política de palavra-passe configurado diretamente no utilizador.
Os grupos de política de palavra-passe são priorizados nas definições do ambiente. Se vários grupos de política de palavra-passe se aplicarem ao utilizador, FoxIDs usa o primeiro grupo correspondente na lista de grupos de política de palavra-passe do ambiente. A política de palavra-passe predefinida do ambiente é usada se nenhum grupo correspondente se aplicar.
Memberships
Os utilizadores são ligados a uma estrutura de acesso através de memberships. Um utilizador pode ser ligado a várias estruturas de acesso através de várias memberships e a vários nós dentro de cada estrutura.
Uma membership:
- Aplica-se tanto a utilizadores internos como a utilizadores externos
- Refere um nó numa estrutura de acesso
- Pode opcionalmente incluir uma hora de início e de fim de validade
As memberships são geridas no FoxIDs Control Client:
- Na página Internal Users para utilizadores internos
- Na página External Users para utilizadores externos
- Na página Access Structures para gestão user-centric de memberships
Acesso resolvido no login
No login, o FoxIDs resolve as memberships do utilizador e percorre a hierarquia de nós desde o nó atribuído até ao nó raiz.
O resultado resolvido inclui:
- Caminhos efetivos de nós
- Claims efetivos da hierarquia
- Claims qualificados por caminho
Estes valores ficam disponíveis antes de as transformações de claims normais serem executadas, o que significa que podem ser usados diretamente em fluxos existentes de transformação de claims e autorização.
Claims locais
A resolução da estrutura de acesso emite tipos de claim locais fixos.
Os seguintes claims locais estão disponíveis nas transformações de claims:
_local:access_node_local:access_claim_local:access_path_claim
Isto evita tipos de claim dinâmicos enquanto continua a transportar contexto hierárquico nos valores de claim.
Encaminhar claims para aplicações
Cada estrutura de acesso inclui a definição Forward access structure claims to applications, que por predefinição está ativada.
Se estiver ativada, os claims de acesso resolvidos são encaminhados para as aplicações.
Se estiver desativada, o acesso resolvido continua disponível localmente dentro das transformações de claims, mas os claims de acesso resolvidos não são encaminhados para as aplicações.
Casos de uso típicos
- Modelar acesso específico por cliente para utilizadores internos e externos
- Atribuir utilizadores a departamentos e funções através de memberships
- Resolver responsabilidades de approver ou reader a partir de uma hierarquia
- Encaminhar claims de acesso resolvidos para aplicações quando necessário