Gestione dei provider di identità
È possibile impostare il login federato tra un dominio di Identity e un provider di identità esterno. Ciò consente agli utenti di collegarsi e accedere alle risorse Oracle Cloud Infrastructure utilizzando i login e le password esistenti gestiti dal provider di identità.
Criterio o ruolo richiesto
- Essere membro del gruppo Administrators
- Assegnare il ruolo di amministratore del dominio di Identity o di amministratore della sicurezza
- Essere membro di un gruppo a cui sono state concesse le autorizzazioni
manage identity-domains
Per ulteriori informazioni sui criteri e sui ruoli, vedere Ruoli del gruppo di amministratori, dei criteri e dell'amministratore, Introduzione ai ruoli dell'amministratore e Panoramica sui criteri IAM.
Informazioni sui provider di identità e sui provider di servizi
Informazioni sui provider di identità e sui provider di servizi.
Un provider di identità, noto anche come autorità di autenticazione, fornisce l'autenticazione esterna per gli utenti che desiderano collegarsi a un dominio di Identity utilizzando le credenziali del proprio provider esterno. Sebbene un dominio di Identity possa fungere da provider di identità per un provider di servizi di terze parti, in questo contesto in cui si basa su un provider di identità per autenticare gli utenti che accedono al dominio di Identity, il dominio di Identity è il provider di servizi. Più in generale, puoi anche pensare a Oracle Cloud Infrastructure come fornitore di servizi perché fornisce i servizi e le risorse a cui gli utenti desiderano accedere.
AD esempio, è possibile che l'organizzazione desideri che gli utenti accedano e accedano a Oracle Cloud Services utilizzando le credenziali ADFS (Microsoft Active Directory Federation Services). In questo caso, Microsoft AD FS funge da provider di identità (IdP) e il dominio di Identity funge da provider di servizi (SP). MS AD FS autentica l'utente e restituisce un token contenente le informazioni di identità e autenticazione al dominio di Identity (AD esempio, il nome utente e l'indirizzo di posta elettronica dell'utente). Questo token di sicurezza è firmato digitalmente da IdP. L'SP verifica la firma nel token e quindi utilizza le informazioni sull'identità per stabilire una sessione autenticata per l'utente. Questo è noto come Single Sign-On federato in cui a un utente viene richiesta la verifica delle credenziali in un dominio e viene concesso l'accesso a un altro dominio.
Per federare un bridge Microsoft Active Directory, vedere Impostazione di un bridge Microsoft Active Directory (AD).
Informazioni sui certificati digitali
Un certificato digitale è come un passaporto elettronico che aiuta una persona, un computer o un'organizzazione a scambiare informazioni in modo sicuro su Internet utilizzando la crittografia a chiave pubblica. Un certificato digitale può essere definito certificato a chiave pubblica.
Proprio come un passaporto, un certificato digitale fornisce informazioni identificative, è resistente alla falsificazione e può essere verificato perché è rilasciato da un'agenzia ufficiale di fiducia. Il certificato può contenere il nome del titolare del certificato, un numero di serie, le date di scadenza, una copia della chiave pubblica del titolare del certificato (utilizzata per la cifratura di messaggi e la verifica di firme digitali) e la firma digitale dell'autorità di certificazione (CA) in modo che il destinatario sia in grado di verificare che il certificato è reale.
Per verificare le firme dei provider di identità esterni, il provider di servizi memorizza le copie dei propri certificati di firma. Quando il provider di servizi riceve un messaggio firmato da un provider di identità, prima che il certificato memorizzato venga utilizzato per verificare la firma, il certificato deve essere verificato come valido. La convalida del certificato include la verifica che il certificato non sia scaduto. Una volta convalidato il certificato, quest'ultimo viene utilizzato per verificare la firma sul messaggio.
Per completare questa operazione, la chiave pubblica incorporata nel certificato deve corrispondere alla chiave privata utilizzata dal provider di identità per firmare il messaggio.
Le specifiche SAML non richiedono un controllo della scadenza, pertanto i login SAML possono continuare a funzionare dopo la scadenza dei certificati. La risposta SAML viene comunque convalidata con i certificati, ma la scadenza viene ignorata.
Che cosa accade alla scadenza del certificato di un provider di identità?
- Ottenere il nuovo certificato di firma dal provider di identità. Potrebbe essere pubblicato dal provider di identità per il download self-service oppure potrebbe essere necessario contattare l'amministratore del provider di identità.
- Caricare il nuovo certificato di firma nella configurazione del dominio di Identity per il provider di identità.
- Se il provider di identità ha eseguito il rollover della coppia di chiavi privata/pubblica di firma (anziché riemettere solo un nuovo certificato per la coppia di chiavi esistente), è necessario aggiornare la configurazione del provider di identità per iniziare a utilizzare le nuove chiavi per firmare i messaggi. Anche in questo caso, potrebbe essere self-service o richiedere il coordinamento con l'amministratore del provider di identità.
Se il provider di identità esegue il rollover della coppia di chiavi di firma, l'autenticazione SSO avrà esito negativo durante il periodo di tempo compreso tra il passo 2 e il passo 3 precedente. Per questo motivo, l'aggiornamento del certificato viene in genere coordinato tra il provider di identità e gli amministratori del dominio di Identity.
Informazioni sul provisioning just-in-time SAML
Il provisioning JIT ( Just-In-Time) SAML automatizza la creazione dell'account utente quando l'utente tenta per la prima volta di eseguire il servizio SSO per la prima volta e l'utente non esiste ancora nel dominio di identità. Oltre alla creazione automatica degli utenti, JIT consente di concedere e revocare le appartenenze ai gruppi come parte del provisioning. È possibile configurare JIT per aggiornare gli utenti con provisioning eseguito in modo che gli attributi degli utenti nell'area di memorizzazione del provider di servizi (SP) possano essere mantenuti sincronizzati con gli attributi dell'area di memorizzazione utenti del provider di identità (IdP).
Vantaggi
- Il footprint degli account utente nel dominio di Identity è limitato agli utenti che effettivamente eseguono l'accesso tramite SSO federato, anziché a tutti gli utenti nella directory utente dell'IdP.
- Costi amministrativi ridotti in quanto gli account vengono creati su richiesta nell'ambito del processo SSO e le aree di memorizzazione del provider di identità e del provider di servizi non devono essere sincronizzate manualmente.
- I nuovi utenti aggiunti in seguito all'area di memorizzazione utenti del provider di identità non richiederanno agli amministratori di creare manualmente gli account del provider di servizi corrispondenti (gli utenti saranno sempre sincronizzati).
Funzionamento
Quando si accede, l'utente: | Flusso |
---|---|
Esiste nel provisioning SP e JIT è abilitato. | Flusso SSO normale. |
Non esiste nel provisioning SP e JIT non abilitato. | Flusso di errore SSO normale. |
Non esiste in SP e l'utente di creazione JIT è abilitato. | L'utente viene creato e popolato con gli attributi di asserzione SAML, come mappato nella configurazione JIT. |
Esiste nell'aggiornamento SP e JIT è abilitato. | I valori degli attributi utente vengono aggiornati con gli attributi di asserzione SAML, come mappato nella configurazione JIT. |