SAML2 vs OAuth - Quali sono alcune relazioni ragionevoli?

12

Ho un servizio che consente l'accesso SSO tramite SAML2. Quando viene utilizzato SAML2, deleghiamo l'intero processo di autenticazione al provider di identità.

Stiamo pensando di aggiungere OAuth per supportare alcune applicazioni mobili. (Non vogliamo che l'utente debba accedere costantemente.)

È abbastanza ovvio come tutto funzionerà insieme quando useremo la nostra autenticazione Username / Password, dato che controlliamo l'intero stack.

Tuttavia, come OAuth interagirà con SAML2 SSO? Ad esempio, cosa si deve fare per invalidare le concessioni di OAuth se il provider di identità rimuove un utente? Quali altri trucchi (e speriamo soluzioni standard) ci sono?

    
posta brendanjerwin 06.04.2013 - 17:43
fonte

3 risposte

2

L'unica implementazione di questa combinazione che conosco è Salesforce. Quello che stai cercando di fare è una configurazione complessa - entrambi i protocolli non sono semplici e ci sono problemi nella loro interazione, come quella che hai menzionato.

Dai un'occhiata a questo documento (che aspetto ha l'implementazione SF dall'esterno) - link

e controlla questa bozza (personalmente non l'ho esplorata, ma riguarda specificamente il tuo caso link

    
risposta data 08.04.2013 - 09:10
fonte
5

Il bridging dei framework SAML e OAuth 2.0 è un problema ben compreso. Il seguente stack di specifiche IETF fornisce una soluzione standard:

  • Se osservi la specifica OAuth 2.0 (RFC 6749) e i suoi definizione dell'endpoint del token - questo è fondamentalmente un endpoint del server OAuth che restituisce un token di accesso in cambio di un " concessione " - un concetto aperto di qualcosa che è ritenuto appropriato per concedere all'app client il problema di un token di accesso . Nel tipico scenario OAuth questo è un codice di autorizzazione che indica che l'utente è stato precedentemente autenticato e dato il loro consenso. Ma la sovvenzione potrebbe anche essere qualcos'altro.

  • C'è un'ulteriore specifica IETF chiamata draft-ietf-oauth-assertions-16 che si basa sullo standard RFC 6749 che afferma che la concessione può anche essere un'asserzione (una dimostrazione firmata di qualcosa) e definisce i parametri necessari per la richiesta di token.

  • Infine, c'è draft-ietf-oauth-saml2-bearer- 20 , che specifica in che modo questa asserzione può essere un'asserzione del portatore SAML 2.0.

Questo meccanismo standard per convertire un'asserzione SAML in un token di accesso OAuth 2.0 è essenzialmente tutto ciò che è necessario per il bridge dei due framework.

Per garantire che la rimozione degli utenti sia correttamente riflessa dai sistemi di autorizzazione, ci sono due approcci che possono essere combinati:

  • Rendi i token di accesso OAuth 2.0 di breve durata. Questo costringerà il client a ripetere il processo di autorizzazione quando il token scade e, se l'utente non esiste più, l'autenticazione fallirà e non verrà emessa alcuna concessione (asserzione SAML).
  • Fornisci un'API per revocare i token di accesso OAuth 2.0 emessi, vedi RFC 7009 per i dettagli.
risposta data 15.05.2014 - 09:52
fonte
3

OAuth è un lavoro con frame autorizzazione . dal RFC6749

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service

E SAML è un autenticazione framework. Le asserzioni SAML contengono informazioni di autenticazione. SAML comune viene utilizzato per SSO ma lo standard SAML contiene anche un %codice%. Che può essere utilizzato per il trasporto di alcune informazioni di autorizzazione.

Puoi ottenere ulteriori informazioni dalla documentazione SAML qui .

La domanda non fornisce dettagli sull'implementazione del tuo sistema, ma ti suggerirei di utilizzare le funzionalità di autorizzazione di SAML 2.0 invece di provare a unire due standard completamente diversi che servono a scopi diversi

    
risposta data 06.04.2013 - 20:57
fonte

Leggi altre domande sui tag