Sto lavorando su una serie di applicazioni che richiedono autenticazione e autorizzazione.
Puoi indicarmi la direzione giusta per un progetto di architettura per questo quando voglio avere più servizi in esecuzione e come gestire esattamente il servizio per l'autenticazione del servizio e l'utente per l'autenticazione del servizio?
Probabilmente farò tutto questo attraverso OAuth2 ecc, ma non sono sicuro di quale sia il modo corretto di distribuire questo.
Speriamo che questo aiuti.
Sistemi di gestione delle identità
Il sistema di gestione dell'identità è spesso definito da fonti attendibili. Questi sono i sistemi su cui facciamo affidamento per una fonte di registrazione per un individuo. Non sono davvero un singolo pezzo, comprano una combinazione di design di sistemi per gestire le persone.
Origine attendibile dei dati di identità
Si tratta di dati di persone, in genere presenti nei sistemi di gestione delle risorse umane. Sono di ampia portata e possono essere semplici come AD per una piccola organizzazione.
Autorizzazione / Autenticazione Trusted Source
Questo è un sistema o sistemi che la tua organizzazione utilizza per AAA. In molte organizzazioni, questo è solo l'Active Directory di MicroSoft, tuttavia, ci sono diversi servizi basati su directory e le organizzazioni più grandi possono avere divisioni di sistema su diverse fonti.
Single Sign On
La maggior parte delle organizzazioni che utilizzano SSO all'interno dell'organizzazione utilizza probabilmente una sorta di Federate Identity Service che consente di avere un singolo ID su più sistemi AAA.
I moderni servizi federati consentono sia le comunicazioni SAML che OAuth 2.0. Se vuoi essere tecnico, OAuth non è mirato all'autenticazione, è l'autorizzazione. Fornisce un meccanismo per lo scambio di autenticazione, ma non è questo il suo intento.
SAML è in esecuzione per entrambi ed è tipico per i servizi SSO Enterprise.
Se si tratta di applicazioni personalizzate, uno standard che ho aggiunto al mio lavoro di sviluppo è JWT (Token Web JSON) che non è realmente SSO per-say, ma più un meccanismo per abilitare le funzionalità SSO nelle moderne applicazioni, ma può gestire sia l'autenticazione che l'autorizzazione.
Esempi di sistemi IDM comuni
Lavoro con entrambi questi sistemi. Ho molte riserve su di loro. Sailpoint è più moderno, Oracle è ben Oracle (un sacco di alti / un sacco di bassi). Penso sempre che potrei costruirne uno migliore (che potrei tentare un giorno di divertimento).
Impostazioni fai da te
Comprendi che IDM / IAM / IdAM (o qualsiasi altro elemento tu voglia) sono progettati per fornire un insieme comune di funzioni amministrative attorno alle persone e accesso alle risorse. Ciò include l'essere un repository centrale per identificare l'accesso, la gestione dei ruoli, la distribuzione dei criteri e il provisioning / de-provisioning delle risorse. Wiki come riferimento.
Il tuo obiettivo reale suona meno come IDM e più come la gestione delle risorse, I.E qualcosa che non è raggiunto da questi sistemi in particolare. Poche cose:
Penso che potresti voler iniziare con i Servizi federati e ricercarli. Questo ti darà una comprensione di quale sia il loro scopo. La maggior parte delle organizzazioni che guardano all'SSO su larga scala stanno cercando servizi federati per semplificare la cosa.
È qui che entra in gioco il termine negozio MicroSoft, così detto perché tutte le loro app sono MS e possono autenticarsi in AD. Non sono mai stato a un'organizzazione che aveva questo ma, Complimenti se hai questa semplicità.
Consigli generali per la distribuzione :
Solitamente OpenID Connect e OAuth2 sono usati per scopi SSO:
L'autorizzazione è più difficile da dare consigli generali poiché di solito dipende dalla logica aziendale. Inoltre non ci sono buoni standard in quell'area (XACML sembra complesso per la maggior parte dei casi e non adatto allo stack JSON + REST). In casi semplici, gli ambiti OAuth2 sono sufficienti, in casi più complessi le regole di autorizzazione possono essere implementate all'interno di diversi servizi separatamente , ma gestiti centralmente (ad esempio, il servizio registrerà i ruoli forniti all'interno di IDM).
È possibile acquistare un abbonamento di fornitori di soluzioni IDaaS come OKTA, Ping ecc. Ping ha esclusivamente un accesso Ping prodotto per OAuth2.0. L'implementazione sarà guidata dal fornitore di soluzioni IDaaS stesso studiando l'architettura.
Leggi altre domande sui tag authentication oauth identity access-control user-management