Informazioni sui criteri dei provider di identità
Informazioni sui criteri del provider di identità.
Un criterio del provider di identità consente di definire quali provider di identità sono visibili nella pagina Accedi quando un utente accede a un'applicazione specifica o tenta di accedere alle risorse protette da un dominio di Identity. I criteri del provider di identità possono anche decidere se gli utenti eseguono l'autenticazione in un dominio di Identity tramite provider di identità o con un fattore di autenticazione locale.
Il seguente tipo di provider di identità disponibile in un dominio di Identity:
-
Provider di identità SAML: questo tipo di provider di identità supporta lo standard SAML 2.0 (Security Assertion Markup Language 2.0). Si utilizza un provider di identità SAML quando si desidera stabilire l'attendibilità tra un provider di identità compatibile con SAML, ad esempio Active Directory Federation Services, in modo che gli utenti di un'organizzazione possano accedere alle risorse protette dal dominio di Identity.
Se si desidera che gli utenti vengano reindirizzati automaticamente a un provider di identità SAML specifico in modo che possano accedere a un'applicazione, assicurarsi che al criterio del provider di identità associato all'applicazione sia assegnato solo il provider di identità SAML. Se al criterio del provider di identità sono assegnati molti provider di identità, agli utenti viene richiesto di selezionare uno dei provider di identità dalla pagina Connetti.
-
Provider di identità social: collegando un account utente del dominio di Identity agli account social di un utente, l'utente può accedere a un dominio di Identity utilizzando le proprie credenziali social, ad esempio Facebook, Google, LinkedIn, Microsoft e X (precedentemente Twitter).
-
Provider di autenticazione senza password: consente agli utenti di ignorare l'autenticazione basata su modulo Web standard. L'autenticazione senza password consente l'accesso alla risorsa protetta senza la necessità di inserire sempre il nome utente e la password. Tuttavia, la prima volta che Accedi utilizza il form di login standard.
-
Provider di identità locale (IDP locale): l'autenticazione in un dominio di Identity viene eseguita localmente dall'utente che fornisce le proprie credenziali (nome utente e password) nella pagina Connetti.
- E-mail: invia un passcode monouso all'indirizzo di posta elettronica principale dell'utente da utilizzare come metodo di verifica per l'autenticazione. L'indirizzo e-mail principale dell'utente è definito nell'account dell'utente.
- Notifica applicazione mobile: invia una notifica push contenente una richiesta di approvazione per consentire o negare un tentativo di login. Le notifiche push sono un modo semplice e veloce per autenticarsi. Dopo che l'utente ha inserito il nome utente e la password, viene inviata una richiesta di login all'app sul suo telefono. L'utente tocca Consenti di eseguire l'autenticazione.
- Passcode applicazione Mobile: un'applicazione di autenticazione quale l'applicazione Oracle Mobile Authenticator (OMA) genera un passcode monouso. Questo passcode può essere generato anche quando il dispositivo dell'utente è offline. Dopo che l'utente ha immesso il nome utente e la password, viene visualizzato un prompt per il passcode. L'utente ottiene un passcode generato dall'applicazione, quindi immette il codice.
- Messaggio di testo: dopo che l'utente ha immesso il nome utente e la password, un passcode viene inviato come messaggio di testo al dispositivo dell'utente. L'utente immette il codice per completare l'accesso.
- Password-nomeutente: l'utente esegue l'autenticazione fornendo le proprie credenziali (nome utente e password) nella pagina Connetti.
Il criterio del provider di identità consente di configurare la visualizzazione dell'autenticazione locale nella pagina Accedi per l'utente.
Ad esempio, si supponga di aver creato diversi provider di identità social e provider di identità SAML e di voler configurare quali di questi provider di identità vengono visualizzati nella pagina Connetti quando l'utente tenta di eseguire l'autenticazione nel dominio di Identity utilizzando una determinata applicazione. Senza i criteri del provider di identità, non è stato possibile configurarlo. Pertanto, se tutti questi provider di identità SAML e social fossero attivati e impostati per essere visualizzati nella pagina Connetti, verranno visualizzati tutti.
Il dominio di Identity fornisce un criterio del provider di identità predefinito che contiene una regola del provider di identità predefinita. A questa regola è assegnato il fattore di autenticazione locale nome utente-password. In questo modo, al minimo, gli utenti possono eseguire l'autenticazione con i loro nomi utente e password. Tuttavia, è possibile basarsi su questo criterio predefinito aggiungendovi altre regole del provider di identità. Aggiungendo queste regole, è possibile impedire che alcuni provider di identità siano disponibili per gli utenti per l'autenticazione nel dominio di Identity. In alternativa, è possibile consentire ad altri provider di identità di essere disponibili solo per gli utenti che accedono al dominio di Identity da un indirizzo IP contenuto in uno dei perimetri di rete. Sia la console Profilo personale che la console di amministrazione utilizzano le regole del provider di identità assegnate al criterio del provider di identità predefinito.
Si supponga che un'azienda abbia limitazioni relative a chi può connettersi al dominio di Identity in locale (fornendo i nomi utente e le password) e a chi deve utilizzare un provider di identità esterno. I dipendenti dell'azienda devono eseguire l'autenticazione utilizzando Active Directory Federation Services (AD FS), gli appaltatori e i partner devono utilizzare i propri provider di identità SAML e tutti gli altri utenti (AD esempio i consumatori) possono utilizzare i propri nomi utente e password o un provider di identità social.
Per raggiungere questo obiettivo, è possibile creare due regole del provider di identità per il criterio del provider di identità predefinito. La prima regola è applicabile solo ai dipendenti della società. Questi utenti devono eseguire l'accesso con AD FS che è il provider di identità dei dipendenti. La seconda regola è applicabile solo agli utenti con nomi utente che terminano con @partner1.com
. Possono connettersi al provider di identità SAML partner 1. La terza regola è applicabile solo agli utenti con nomi utente che terminano con @partner2.com
. Può connettersi al provider di identità SAML del partner 2. La regola finale è una regola generale per tutti gli utenti (consumatori). Questi utenti possono utilizzare le password locali o un provider di identità social.
Poiché è possibile definire diverse regole del provider di identità per un criterio del provider di identità, il dominio di Identity deve conoscere l'ordine in cui le regole devono essere valutate. A tale scopo, è possibile impostare la priorità delle regole. Per l'esempio precedente, è possibile valutare prima la regola dipendente dell'azienda. Se un utente soddisfa i criteri di questa regola, ovvero se è un dipendente, è necessario eseguire l'autenticazione con AD FS. Gli utenti che non sono dipendenti non soddisfano i criteri di questa regola del provider di identità e pertanto viene valutata la regola con la priorità più alta successiva. In questo esempio, si tratta della regola partner 1 in cui il nome utente dell'utente deve terminare con @partner1.com
. Questi utenti devono eseguire l'autenticazione utilizzando il provider di identità SAML del partner 1. Per gli utenti che non sono dipendenti o che non dispongono di nomi utente che terminano con @partner1.com
, il dominio di Identity valuta la regola con il numero di priorità più alto successivo: la regola partner 2 in cui il nome utente dell'utente deve terminare con @partner2.com
. Per eseguire l'autenticazione, questi utenti devono utilizzare il provider di identità SAML del partner 2. Tutti gli altri utenti soddisfano i criteri della regola catch-all in modo da poter utilizzare le password locali o un provider di identità social per collegarsi.
Oltre al criterio del provider di identità predefinito, è possibile creare criteri del provider di identità e associarli ad applicazioni specifiche. Si supponga di avere diverse app e di voler assegnare diversi provider di identità a ciascuna app. Ad esempio, si potrebbero avere due app e si desidera che gli utenti eseguano l'autenticazione da Facebook o LinkedIn. È pertanto possibile disporre di un criterio del provider di identità per un'applicazione e il provider di identità social di Facebook e di un altro criterio del provider di identità solo per la seconda applicazione e il provider di identità social di LinkedIn.
Un dominio di Identity visualizza al massimo quattro provider di identità nella pagina Collega. Se si assegnano più di quattro provider di identità a un criterio del provider di identità, nella pagina viene visualizzato un collegamento Visualizza tutto. Selezionare il collegamento e vengono visualizzati tutti i provider di identità associati al criterio.