Uso dell'accesso implicito per i domini predefiniti

Criteri di accesso

Per ridurre al minimo il rischio che l'amministratore del dominio di Identity predefinito venga bloccato, il sistema crea un workflow di accesso di interruzione implicito. Questo flusso di lavoro viene creato quando si applicano le seguenti condizioni:

• L'utente che accede alla console è un amministratore.
• L'utente sta accedendo al dominio predefinito.
• Non esiste alcuna istruzione di negazione specifica nel criterio di accesso applicabile per la console.

Esempio:

Questo scenario utilizza i seguenti utenti: admin1, admin2, admin3 e user1.

Requisiti:

• Tutti gli utenti sono membri del dominio predefinito.
• Il criterio di accesso viene configurato con le regole riportate di seguito nello stesso ordine.
  Nota
  
  L'utente admin3 è membro di group1.
  • Articolo 1: Allow all administrators access except exclude the admin2.
  • Articolo 2: Allow all users who are members of group group1 access.

Risultati:

• admin1: accesso consentito. Nessuna regola di accesso corrisponde, nessuna negazione esplicita, amministratore e accesso al dominio predefinito.
• admin2: accesso negato. All'utente admin2 è esplicitamente negato l'accesso nella Regola 1.
• admin3: accesso consentito. L'utente admin3 è un amministratore e un membro di group1.
• user1: accesso negato. L'utente user1 non corrisponde ad alcuna regola.

Criterio provider di identità

Il sistema attiva un workflow di accesso di interdizione implicito per l'accesso alla console quando la regola del provider di identità del criterio del provider di identità è configurata con un solo provider di identità SAML o SOCIAL (OIDC). In questi casi, il sistema mostra sempre la pagina di connessione della console invece di reindirizzare l'utente a un partner di federazione remoto quando si accede al dominio predefinito della console.