Usando Acesso Implícito para Domínios Padrão

Política de Sign-On

Para minimizar o risco de o administrador do domínio de identidades padrão ser bloqueado, o sistema cria um workflow de interrupção implícito. Esse fluxo de trabalho é criado quando as seguintes condições se aplicam:

• O usuário que está acessando a Console é um administrador.
• O usuário está acessando o domínio padrão.
• Não existe nenhuma instrução de negação específica na política de acesso aplicável para a Console.

Exemplo:

Esse cenário usa os usuários a seguir, admin1, admin2, admin3 e user1.

Requisitos:

• Todos os usuários são membros do domínio Padrão.
• A política de sign-on é configurada com as regras a seguir na mesma ordem.
  Observação
  
  O usuário admin3 é membro do group1.
  • Regra 1: Allow all administrators access except exclude the admin2.
  • Regra 2: Allow all users who are members of group group1 access.

Resultados:

• admin1: Acesso permitido. Nenhuma das regras de sign-on corresponde, nenhuma negação explícita, administrador e acesso ao domínio padrão.
• admin2: Acesso negado. O acesso explicitamente negado ao usuário admin2 na Regra 1.
• admin3: Acesso permitido. O usuário admin3 é um administrador e um membro do group1.
• user1: Acesso negado. O usuário user1 não corresponde a nenhuma regra.

Política do Provedor de Identidade

O sistema aciona um workflow de interrupção implícita para acesso à Console quando a regra do provedor de identidades da política do provedor de identidades é configurada com apenas um provedor de identidades SAML ou SOCIAL (OIDC). Nesses casos, o sistema sempre mostra a página de acesso da Console em vez de redirecionar o usuário para um parceiro de federação remota, ao acessar o domínio Padrão da Console.