Utilizzo di più servizi di identità oAuth simultaneamente

Question

Utilizzo di più servizi di identità oAuth simultaneamente

#1 da (1 voti)
#2 da (1 voti)

7

Questa domanda è in qualche modo acedemica. Mentre mi istruisco sul tema della sicurezza tramite un token bearer per un servizio back-end a cui sto lavorando, e in particolare su oAuth2, mi sono venute in mente alcune domande:

Se si dovesse affidare in outsourcing il servizio di provider di identità / autorizzazione, si crea una dipendenza da quel fornitore di servizi. Quanto sarebbe dispiaciuto passare a un nuovo fornitore di servizi oAuth2?
Che cosa succede se il fornitore di servizi "non riesce" (scompare da Internet o ha i loro sistemi compromessi o cambia le loro politiche in un modo che è incompatibile con i tuoi requisiti, ecc.)

Come metodo per ridurre la dipendenza mi è venuto in mente che potrei essere in grado di configurare il server delle risorse per verificare ogni richiesta di avere due token, da due diversi fornitori di servizi, ad esempio SP-A e SP-B.

Per fare in modo che gli utenti [del cliente] debbano "essere registrati" sia in SP-A che in SP-B. Ciò implicherebbe che durante la procedura di registrazione, i dettagli degli utenti vengano inviati e i record creati sia in SP-A che in SP-B.

Gli sviluppatori client avranno un impatto sul fatto che hanno bisogno di sviluppare le loro applicazioni per registrare gli utenti con due provider oAuth e devono ottenere i codici di autorizzazione di due provider. Per gli utenti finali l'impatto potrebbe essere ridotto al minimo, ma se un cliente desidera utilizzare gli ID OpenID esistenti degli utenti per effettuare la registrazione iniziale e l'autenticazione di accesso, l'utente dovrebbe autorizzare l'accesso DUE ai propri dati.

L'unico vantaggio immediato potrebbe essere quello di impostare un flag globale nel back-end per ciascuno di SP-A e SP-B, per ignorare / bypassare quel provider, nel caso sia necessario.

Potresti anche utilizzare diverse politiche, ad esempio richiedere un token valido da tutti i provider oAuth o da almeno un provider oAuth, ecc., in base ai tuoi requisiti.

Ovviamente si dovrebbe sempre verificare le credenziali di un Authorization Provider, registrare, ecc. e provare a valutare i rischi.

oauth identity-management

posta Johan 27.01.2015 - 17:17

fonte

2 risposte

Leggi altre domande sui tag oauth identity-management

Verifica dei file firmati crittograficamente quando la chiave è stata revocata Sottochiavi di crittografia multiple su smart card hardware

score 1 · Answer 1

Non sono sicuro di cosa intendi. Ecco le mie due ipotesi migliori:

OAuth per autorizzazione

OAuth consente a una terza parte (tu) di accedere alle risorse protette di un utente da un server di risorse (probabilmente un'API) dopo aver ottenuto l'autorizzazione tramite un server di autorizzazione (il provider OAuth).

Il provider OAuth è probabilmente la stessa organizzazione che esegue il server delle risorse. Se l'organizzazione scompare da Internet, non ha davvero senso avere un fornitore diverso per ottenere l'autorizzazione a una risorsa inesistente.
OAuth per autenticazione

C'è anche la possibilità che tu stia facendo riferimento all'utilizzo di un servizio di identità di terze parti per autenticare gli utenti sul tuo sito.

Se questo è il caso, non è necessario legare a un particolare servizio, basta utilizzare OpenID Connect e consentire agli utenti di scegliere il provider che preferiscono.

Puoi offrire pulsanti di traccia rapida per i provider più comuni, ma non sei dipendente da essi.

Ah, le gioie dei servizi federati: -)

Fammi sapere se ho completamente frainteso la domanda.

score 1 · Answer 2

Client developers will be impacted in that they need to develop their applications to register users with two oAuth providers, and must obtain Authorization codes from two providers. [...]

La registrazione di utenti con più provider oAuth e l'ottenimento di codici di autorizzazione da diversi provider oAuth è, come già detto GnP, un problema non teorico, poiché Open ID Connect offre un protocollo standard e persino un metodo di discovery standard per gli endpoint di API. Si scrive il codice per ottenere un codice di autorizzazione e lo si scambia per un ID e un token di accesso una volta, e lo si esegue contro qualsiasi fornitore compatibile (il chilometraggio può variare, tuttavia: ho implementato correttamente il mio codice con le implementazioni Open ID Connect di Google e Microsoft Azure, ma quando ho provato Yahoo, Yahoo non si è comportato secondo le specifiche e non ha dato una ragione per cui non ha ...

Ignorare questa avvertenza, supportando più Identity Provider invece di uno solo è fondamentalmente solo la differenza tra l'utilizzo di una relazione 1: 1 e una relazione 1: n nel database utente - ad es. invece di collegare un singolo ID aperto Connetti l'identificativo del soggetto a ciascuna delle entità utente, progetta il back-end del database per consentire l'aggiunta di un numero arbitrario di esse e ogni volta che vuoi supportare un nuovo provider di identità, in pratica tutto ciò che devi fare (se si comporta in base alle specifiche) è quello di fornire all'applicazione il nome del dominio in cui risiede il documento di scoperta dell'IDP.

but if a client wanted to use users' existing OpenID IdPs to effect initial registration and sign-in authentication, the user would have to authorize TWO access to their data.

Trovo che l'autorizzazione sia il problema più difficile da risolvere, ma non per il motivo che offri, e l'ho solo perché ho una base utenti preesistente con un insieme ben definito di diritti di accesso. Il mio problema è questo: in sostanza, ogni fornitore di Open ID ti fornisce una stringa casuale che identifica un utente, ma come abbinare queste stringhe alle entità dell'utente (e quindi alla loro autorizzazione)? Le stringhe dell'oggetto che ottieni da un IDP sono completamente casuali e non puoi conoscerle in anticipo, quindi se hai una base utente conosciuta per la quale hai definito diversi diritti di accesso, come combaci con un ID che non puoi prevedere una determinata entità utente nel tuo quadro di autorizzazione?

(Il modo in cui ho risolto questo è utilizzare l'indirizzo di posta elettronica che IdP mi fornisce come parte del token id come identificatore univoco, noto per collegare l'identificatore di soggetto di IdP alle entità utente la prima volta che vedo un nuovo l'utente autentica, ma affinché funzioni, devi aver fiducia che l'IdP verifica correttamente gli indirizzi e-mail, una scommessa che non sarei disposto a prendere per ogni IdP là fuori.

Quindi sì, consentire a più provider di identità di generare un lavoro aggiuntivo, ma è soprattutto nella configurazione di diversi modelli di fiducia per diversi IdP. Nel mio caso, mi fido di un token id dal mio IdP principale implicitamente, e accetto solo un piccolo insieme di altri IdP, di cui non mi fido a fornirmi informazioni verificate oltre l'identificativo dell'oggetto del token identità, quindi per questi , Ho bisogno di una seconda soluzione per il problema di corrispondenza / autorizzazione che ho esposto sopra.

Se non hai lavorato con una base utente preesistente, il modo per risolvere il problema di abbinamento sarebbe consentire a un utente di unire le sue identità multiple collegandole tutte allo stesso account utente. Potresti fare ciò facendogli autenticare con un account utente, e poi, mentre è autenticato, digli di autenticarsi con i suoi altri provider di identità. La tua applicazione potrebbe quindi collegare tutte queste identità insieme come appartenenti alla stessa persona / entità utente nel tuo database.