L'utilizzo di token bearer SAML per l'autenticazione degli utenti ai servizi di back-end è una cattiva idea?

Question

Supponiamo di avere un'applicazione front-end che vuole recuperare alcuni dati da un servizio di back-end. (Sì.) Il servizio dovrà verificare che l'utente finale sia autenticato, che sia autorizzato a utilizzare il servizio ed eventualmente a filtrare i dati restituiti in base ai privilegi dell'utente. Nel mio caso, sia l'app front-end che il servizio back-end si affidano ad Azure ACS per l'autenticazione.

Idealmente, il front-end vorrebbe agire per conto del dell'utente autenticato, che suona come una buona misura per l'utilizzo di un token di ActAs (come specificato nella WS-Trust). Tuttavia, risulta che ACS does not currently support ActAs.

Una soluzione alternativa può essere utilizzare il token di trasporto effettivo (il token di avvio nell'app front-end) per l'autenticazione al servizio di back-end. It's not hard to do, ma sarebbe una cattiva idea per qualche motivo?

Answer 1

Dalla tua app di front-end, puoi certamente passare i dati di identità dell'utente finale inviando il token così com'è o inviando gli attributi da esso. Entrambi hanno problemi. Per il primo, se è anche crittografato, i front-end e i back-end dovranno condividere la chiave privata necessaria per decodificarlo; dovranno inoltre condividere restrizioni sul pubblico, ecc. affinché il back-end consideri il token valido per esso. In altre parole, i front-end e back-end saranno UN SOLO relying party, non due. Potrebbe non essere un problema, ma attenzione. In quest'ultimo caso, si finisce per inviare dati utente in modo proprietario che potrebbe aumentare i costi di integrazione e manutenzione nel tempo. In entrambi i casi, è possibile autenticare l'app front-end sul back-end utilizzando un altro tipo di credenziale, ad esempio un certificato utilizzato a livello di trasporto e, quindi, formando un sottosistema attendibile tra di essi.

Una cosa che vorrei suggerire di considerare è OAuth 2. Da this blog post, mi sembra che ACS lo supporti (anche se non ho alcuna esperienza di prima mano). La cosa veramente meravigliosa di OAuth 2 è che cuoce la delega, e NON è QUI quasi complessa come ActAs in WS-Trust. Il risultato netto è lo stesso, cioè il servizio di back-end avrà informazioni sul servizio di chiamata e l'utente finale, ma la quantità di sforzo per farlo configurare in modo incomparabile. I token saranno ancora token al portatore, ma puoi attenuarli fino ad un certo punto usando SSL. Oltre SSL, puoi mettere in atto alcune misure aggiuntive, ma il migliore, IMO, sarebbe se Microsoft avesse fatto qualcosa in ACS come Google ha fatto con i loro token di accesso per gli account di servizio che utilizza chiavi asimmetriche che sono incatenate a una PKI. (Per quanto ne so, Microsoft potrebbe aver già fatto qualcosa del genere, se è così, sei pronto.)

In ogni caso, HTH!