Single Sign-On con il pattern delegato Access Control

L' Enterprise Integration Zone è portato a voi in partnership con MuleSoft . Ulteriori informazioni su come utilizzare il toolchain java con SAP .
 Supponiamo che un'azienda di medie dimensioni ha un numero limitato di API RESTful. Dipendenti della Società sono autorizzati ad accedere a queste API tramite applicazioni web mentre sono dietro il firewall aziendale. Tutti i dati utente vengono memorizzate in un Microsoft Active Directory, e tutte le applicazioni Web sono collegati ad un Security Assertion Markup Language (SAML) provider di 2,0 identità per autenticare gli utenti. Le applicazioni web hanno bisogno di accedere alle API di back-end per conto dell'utente loggato.


La cattura è questa ultima affermazione: "Le applicazioni web hanno bisogno di accedere alle API di back-end per conto dell'utente loggato." Questo suggerisce la necessità di un protocollo di accesso-delega: OAuth. Tuttavia, gli utenti non presentano le loro credenziali direttamente all'applicazione web-si autenticano attraverso un provider di SAML 2.0 di identità. In questo caso, è necessario trovare un modo per scambiare il SAML Token ricevuto nel protocollo SSO SAML 2.0 Web per un OAuth token di accesso, che è definito nel tipo di sovvenzione per la specifica SAML OAuth 2.0. Una volta che l'applicazione Web riceve il token SAML, come indicato al punto 3 della figura di cui sopra, deve scambiare con un token di accesso a parlare con il server di autorizzazione OAuth. Il server di autorizzazione deve fidarsi del provider di identità SAML 2.0. Una volta che l'applicazione web ottiene il token di accesso, è possibile utilizzarlo per accedere alle API di back-end. Il tipo di sovvenzione per SAML OAuth non fornisce un token di aggiornamento. La durata del token di accesso rilasciata dal autorizzazione OAuth deve corrispondere alla durata del token SAML utilizzata nella concessione dell'autorizzazione. Dopo l'utente accede all'applicazione web con un token SAML valido, la web app crea una sessione per l'utente da lì in avanti, e non preoccuparti per la durata del token SAML. Questo può portare ad alcuni problemi. Dire il token SAML scade, ma l'utente ha ancora una sessione del browser valido nell'applicazione web. Poiché il token SAML è scaduto, ci si può aspettare che il token di accesso OAuth corrispondente ottenuto al momento della login utente è scaduto pure. Ora, se l'applicazione Web tenta di accedere a una API di back-end, la richiesta verrà respinta perché il token di accesso è scaduto. In un tale scenario, l'applicazione web deve reindirizzare l'utente alla provider di identità SAML 2.0, ottenere un nuovo token SAML, e di scambio che token per un nuovo token di accesso. Se la sessione al provider di identità SAML 2.0 è ancora vivo, allora questo reindirizzamento può essere reso trasparente per l'utente finale. Questo è uno dei dieci modelli di protezione API trattati nel mio libro Avanzata API di sicurezza . Potete trovare maggiori dettagli su questo dal libro.