Esempi di Federated Identity Management, Servizi di identità di terzi e Single Sign-On

TL; DR:

FIM (o FidM) si riferisce a un concetto astratto di gestione dell'identità. Organizzazioni che hanno impiantato un sistema FIM, lo utilizzano per gestire le identità e la fiducia dei propri utenti al fine di semplificare l'accesso alle risorse.

3PIS è un prodotto che acquisisci da un fornitore. Supporta la configurazione o l'installazione di una FIM e potrebbe o meno fornire una funzionalità SSO per gli utenti.

SSO è un meccanismo inserito in un po 'di software che consente agli utenti di accedere a più servizi o sistemi con un solo accesso o le stesse credenziali di accesso.

(1) SSO is an example of 3PIS

Non esattamente. Un 3PIS può includere un meccanismo per SSO, ma non necessariamente. (Anche se - penso - le più attuali lo fanno.) Non diresti: "Il nostro SSO è un 3PIS". ma piuttosto "Il nostro 3PIS utilizza SSO."

(2) But not all SSO are 3PIS, when the authentication mechanism is devised by the provider of the resource

Bene, sì, un po '. Hai bisogno di un FIM per usare SSO, puoi usare un 3PIS per configurare il tuo FIM. Ma non tutti i sistemi / servizi supportano SSO.

(3) An advantage of FIM is that it can provide SSO

Sì.

(4) FIM does not always provide SSO

Non ne conosco nessuno, ma questo non significa niente.

(5) FIM may use 3PIS mechanism, if the mechanism is devised by an organization not related to any of the providers of the resource

3PIS non è un meccanismo stesso. I provider di identità utilizzano ad es. meccanismi di identificazione basati su certificati per stabilire la fiducia tra gli utenti, il fornitore di servizi e l'organizzazione che utilizza un 3PIS.

(6) FIM may not use 3PIS mechanism, if the mechanism is devised by one of the providers of the resource

Vedi sopra.

Mentre stai ancora studiando, forse vuoi provare a rispondere al resto della tua domanda per conto tuo. Se le cose non sono ancora chiare, cercherò di fornire un altro contesto.

Divulgazione: non sono certificato né con CISSP né ho mai studiato per il loro certificato.

Vorrei aggiungere che "Federated Identity Management" è una brutta etichetta. Identity Management significa creare, gestire e cancellare identità in un repository, come una directory LDAP. I sistemi di gestione federati di "identità" non fanno nulla di tutto questo e dovrebbero essere più correttamente definiti sistemi di "gestione degli accessi federati".

FAM (come sopra) significa che l'applicazione A può scaricare il processo di identificazione e autorizzazione di un utente che desidera accedere alla domanda B. Questo processo può anche scaricare alcune decisioni di autorizzazione (ciò che l'utente può fare nell'app A può essere fino all'app B).

Esistono alcuni protocolli standard più o meno per la federazione, tra cui il SAML (Secure Assertions Markup Language) e OAuth (suppongo che sia l'acronimo di Open Authentication). Un protocollo "also-ran" è il set di protocolli WS-Federation sostenuto da Microsoft e praticamente nessun altro (usato tra ADFS, SharePoint e O365 per esempio).

È possibile dedurre una definizione per la gestione delle identità dall'alto. Può essere abbreviato in "IDM".

Di solito non eseguiamo IDM da soli. Dopo tutto, la maggior parte dei sistemi e la maggior parte delle organizzazioni si preoccupano solo dell'identità come prerequisito per garantire l'accesso a qualcosa. In pratica, facciamo "identità e gestione degli accessi" insieme - cioè gestiamo il ciclo di vita di oggetti che rappresentano persone o processi non umani e allo stesso tempo concedono e revocano i diritti di accesso, come l'appartenenza ai gruppi di sicurezza. La combinazione di identità e gestione degli accessi è abbreviata in IAM.

Alcune aziende di analisti amano concentrarsi sull'aspetto di governance di IAM, come rivedere ciò a cui un dato utente ha accesso e revocare le autorizzazioni non più appropriate. A loro piace così tanto che a volte si riferiscono a IAM come Identity Governance and Administration (IGA). Confuso ancora? È solo un acronimo, si riferisce alle stesse capacità nella realtà.

Il single sign-on è una cosa separata ma correlata. Fai riferimento all'idea FAM qui sopra. Quando l'applicazione B autentica l'utente per conto dell'applicazione A, chiede all'utente di inserire il suo ID e password, o qualsiasi altra credenziale, ogni volta che l'utente si trova nella pagina di accesso dell'applicazione B? Dopo tutto, l'applicazione B potrebbe rilasciare un cookie nel browser dell'utente - diciamo buono per un'ora o un giorno, e se l'utente accede nuovamente all'app A, o forse un'altra app (ad esempio l'app C), che si appoggia anche all'accesso dell'app B pagina, quindi l'app B noterà che ha già autenticato l'utente e recentemente, e non ha più bisogno di farlo di nuovo.

Questo ultimo bit, saltando la procedura di accesso se un processo di autenticazione è stato completato di recente per lo stesso utente, è single sign-on o SSO in breve.

Spero che questo aiuti!