Guida pratica alla sicurezza OAuth e API con CA Layer 7

Transcript

1 WHITE PAPER febbraio 2014 Guida pratica alla sicurezza OAuth e API con CA Layer 7 Semplificare l'implementazione di OAuth per l'organizzazione

2 2 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Sommario Descrizione di OAuth 3 Un semplice esempio di OAuth 4 Questo problema non è già stato risolto? 6 In cosa OAuth 2.0 è diverso dalle versioni precedenti? 6 In cosa consiste la complessità di OAuth? 8 In che modo CA Layer 7 facilita l'implementazione di OAuth? 9 Qual è il vantaggio di un toolkit OAuth? 10 In che modo CA Layer 7 semplifica le cose nei casi d'uso di OAuth a due o tre gambe? 11 Contattare CA Technologies 12

3 3 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Descrizione di OAuth OAuth sta emergendo come standard web per l'autorizzazione di un accesso limitato ad app e dati. È progettato in modo che gli utenti possano concedere accesso limitato alle risorse di cui sono titolari, come immagini che risiedono su siti quali Flickr o SmugMug, a un client di terze parti, come un sito che si occupa di stampare fotografie. In passato, era pratica comune richiedere all'utente di condividere nome utente e password con il cliente, un richiesta apparentemente semplice dietro alla quale si nascondeva un rischio per la sicurezza inaccettabile. In contrasto, OAuth promuove un modello orientato alla massima limitazione possibile dei privilegi, consentendo a un utente di concedere accesso limitato ad app e dati mediante il rilascio di un token a capacità limitata. OAuth è importante perché pone la gestione della delega web nelle mani del titolare effettivo della risorsa. L'utente riesce a mettere in connessione i propri account sulle diverse app web senza il coinvolgimento diretto dei responsabili della sicurezza su ogni sito. Questa relazione può essere di lunga durata, ma allo stesso tempo l'utente ha facoltà di porvi fine facilmente in qualsiasi momento. Uno dei grandi vantaggi che OAuth apporta allacommunity web è la formalizzazione del processo di delega agli utenti della mappatura delle identità. OAuth sta diventando rapidamente uno standard base del web moderno ed è cresciuto ben oltre le sue radici, che affondano nei social media. OAuth è oggi estremamente importante per l'azienda, e viene utilizzato per gestire le risorse aziendali da compagnie di assicurazione, operatori via cavo e perfino operatori sanitari. Gran parte di questa adozione è trainata dall'esigenza aziendale di sostenere client e, in particolare, device mobile sempre più diversificati. Queste organizzazioni stanno implementando aggressivamente le API per soddisfare le esigenze di questo nuovo canale di delivery, e OAuth rappresenta la best practice per l'autorizzazione delle API. Ma è importante riconoscere che OAuth è solo una componente di una soluzione completa di controllo degli accessi e di sicurezza API. È facile concentrarsi sui dettagli del protocollo perdendo di vista il quadro generale della gestione delle API, che comprende una varietà di altri componenti, dalla gestione degli utenti all'auditing, dal throttling al rilevamento delle minacce. Le API rappresentano spesso un collegamento diretto alle app aziendali mission-critical: la loro protezione richiede allora una soluzione di sicurezza di classe enterprise. La mission di CA Layer 7 è fornire l'infrastruttura alle app aziendali compatibili con OAuth. Offriamo soluzioni drop-in, dall'api Proxy a basso costo alla completa soluzione SOA Gateway e Mobile Access Gateway, che si integrano perfettamente con gli investimenti esistenti nella tecnologia IAM, per fornire un modello di autorizzazione coerente in tutta l'azienda. Tutte le soluzioni CA Layer 7 Gateway sono disponibili come immagini virtuali di facile implementazione. CA Layer 7 fornisce inoltre la flessibilità necessaria per eseguire l'integrazione con implementazioni OAuth di terzi che potrebbero non essere del tutto conformi agli standard correnti, isolando così l'azienda dalle modifiche collegate a una tecnologia in rapida evoluzione. Questo white paper di CA Layer 7 Technologies illustra il concetto di OAuth e come realizzarlo con semplicità all'interno della propria organizzazione.

4 4 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Un semplice esempio di OAuth Il mondo dei social media è stato il principale early adopter di OAuth. Facebook e Twitter devono molto del loro successo al fatto di non costituire semplici siti web autonomi, ma piattaforme che promuovono l'integrazione con altre app. I punti di integrazione sono le API RESTful che in genere utilizzano OAuth come modalità di autenticazione, autorizzazione e associazione di account personali diversi. Twitter e Facebook rappresentano ottimi esempi di OAuth in azione. Come molti, probabilmente anche chi legge disporrà di account separati su entrambi questi social media così diffusi. Pur con nomi utente magari simili (ma con password diverse, come dettano le best pratice di sicurezza), questi account rimangono distinti e gestiti su siti diversi. Come è possibile, allora, fare in modo che un tweet di un utente venga visualizzato istantaneamente sulla sua bacheca di Facebook? In passato, sarebbe probabilmente stato necessario memorizzare il nome utente e la password di Facebook nel profilo Twitter. In questo modo, alla pubblicazione di un nuovo tweet, l'app Twitter avrebbe potuto eseguire l'accesso per l'utente e il cross-posting su Facebook. Questo approccio, che ha preso il nome di "password anti-pattern", è sconsigliabile per una serie di ragioni. Affidare a Twitter la propria password Facebook è, semplicemente, eccessivo. Un hacker che compromettesse il sito o un amministratore interno malintenzionato potrebbe sfruttare la password in chiaro dell'utente per pubblicare immagini dannose, bloccare l'accesso dell'utente al suo account Facebook o addirittura eliminarlo. Fortunatamente, Twitter e Facebook utilizzano entrambi OAuth per risolvere il problema. OAuth fornisce un modello di autorizzazione delegata che consente a Twitter esclusivamente di pubblicare post sulla bacheca dell'utente, e nient'altro, come si vede nella Figura 1. Figura 1. OAuth consente a Twitter di inviare tweet all'account Facebook dell'utente, senza utilizzare la password di Facebook. Come consentire i tweet sulla bacheca di Facebook Client 2. Twitter posta i tweet su Facebook a nome dell'utente Proprietario della risorsa (ovvero, l'utente) 1. L'utente posta un nuovo tweet AS (Authorization RS (Resource

5 5 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Dal punto di vista dell'utente, l'interazione è estremamente semplice e intuitiva, come si può vedere nella Figura 2. Dal pannello delle impostazioni di Twitter, l'utente fa clic su un pulsante che lo trasferisce su Facebook, dove esegue l'accesso. Questo crea un'associazione tra i due account separati dell'utente, senza alcun coinvolgimento dei responsabili della sicurezza di Facebook o di Twitter. Una volta autenticato su Facebook, l'utente segue una procedura di consenso mediante la quale può scegliere il sottoinsieme di privilegi da concedere a Twitter per consentire all'app di eseguire operazioni per suo conto. Infine, l'utente ritorna automaticamente a Twitter, dove può riprendere la pubblicazione di tweet, che vengono visualizzati anche sulla sua bacheca di Facebook. Questo rapporto continua a tempo indeterminato, o fino a quando l'utente decide di interromperlo, utilizzando i comandi presenti nella pagina delle impostazioni. Figura 2. In che modo un utente autorizza Twitter a inviare tweet sulla propria bacheca di Facebook. 1. Nessuna autorizzazione a postare su Facebook 2. Accesso a Facebook per autorizzare Twitter a postare sulla bacheca 3. Concessione dell'autorizzazione a postare su Facebook Per l'utente si tratta di un processo semplice e intuitivo e, infatti, questo rappresenta molta parte del fascino di OAuth. Ma dietro a questa apparente semplicità c'è un'interazione molto più complessa tra i siti, spesso chiamata la "danza" di OAuth. OAuth a tre gambe è la definizione informale dello scenario descritto qui, che rappresenta il caso d'uso più tipico della specifica OAuth 1.0a, attualmente pubblicata come RFC Questa specifica è dettagliata ma sorprendentemente limitata. Essa definisce il flusso di reindirizzamento che consente all'utente di associare i suoi account, autorizzare un sottoinsieme limitato di operazioni e restituire un token opaco che Twitter può continuare a utilizzare per l'accesso, in modo sicuro, in sostituzione di una password onnicomprensiva. La specifica include in dettaglio, almeno nella versione 1.0, anche un metodo per collegare il token ai contenuti dei parametri utilizzando firme digitali, consentendo così controlli di integrità sui contenuti inviati tramite canali non crittografati. Uno dei punti di forza della specifica OAuth 1.0a è che, anziché tentare di definire un framework di autorizzazione generalizzato, punta invece a offrire una soluzione alla diffusa problematica di design descritta sopra. Si è trattata di un'iniziativa nata dal basso, da persone che avevano un problema da risolvere: e la soluzione è arrivata con un tempismo perfetto. Non sorprendentemente, ha avuto un successo enorme ed è stata implementata su siti come Google, DropBox, SalesForce, Foursquare e LinkedIn. OAuth, tuttavia, si sta evolvendo. La versione 2, pubblicata nel mese di ottobre 2012, si propone ambiziosamente di soddisfare un insieme molto più generalizzata di casi d'uso. Questo naturalmente aggiunge complessità alla soluzione e aumenta le difficoltà incontrate dagli sviluppatori che cercano di implementare questo metodo per proteggere le API aziendali.

6 6 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Questo problema non è già stato risolto? Non esistono processi formali completamente definiti per risolvere il problema dell'autorizzazione delegata affrontata da OAuth. I suoi designer hanno considerato le alternative e hanno prodotto soltanto un numero limitato di soluzioni, totalmente completamente proprietarie. Anche OAuth è stato certamente inventato per necessità, l'apertura era un obiettivo chiave. È assolutamente possibile che SAML, più spesso utilizzato per il Single Sign-On (SSO) federato, venga utilizzato come formato token per la comunicazione delle operazioni delegate tra siti che utilizzano il tipo di token mittente-garante. Tuttavia, SAML di per sé non definisce il flusso delle interazioni per impostare la relazione di trust o le associazioni tra account. Inoltre, in quanto formato XML molto complesso, SAML non si sposa bene con le pratiche di sviluppo correnti, centrate su principi RESTful e su semplici strutture di dati JSON. OpenID ha tentato di fornire un sign-on web unico. In un mondo perfetto, dove OpenID fosse universale, OAuth non sarebbe probabilmente mai stato necessario. Ma nonostante il successo ottenuto su siti autorevoli come Yahoo e WordPress, OpenID non è mai arrivato a un'adozione diffusa. OpenID può comunque avere una seconda possibilità di successo a motivo del modo in cui va a completare OAuth. In cosa OAuth 2.0 è diverso dalle versioni precedenti? OAuth 1 si è evoluto molto rapidamente a causa dell'elevata richiesta; forniva una soluzione a un problema comune e la sua adozione da parte delle principali app social ha contribuito alla sua ampia diffusione. L'implementazione più comune al momento è 1.0a, che incorpora una leggera modifica rispetto alla specifica originale, finalizzata a risolvere una vulnerabilità di sicurezza. La specifica 1.0a è ben progettata e abbastanza completa, ma solo per un insieme ristretto di casi d'uso. Probabilmente, questo è uno dei suoi punti di forza: fa una cosa sola e lo fa molto bene. OAuth 1.0 è ampiamente supportata, con librerie disponibili nella maggior parte delle lingue, ma risente notevolmente dell'effetto "fai-da-te": una caratteristica forse positiva per il singolo sviluppatore, ma decisamente non per l'azienda. OAuth 1.0a presenta alcune complessità ulteriori che ne hanno ostacolato un'adozione più ampia. Questa specifica trasferisce la complessità ai client, in particolare in relazione all'elaborazione della crittografia, il che può presentare difficoltà di codifica in linguaggi come JavaScript. OAuth 1.0a richiede ad esempio che i client firmino i parametri HTTP: un'ottima idea per le trasmissioni non crittografate (un modello di utilizzo comune sul web convenzionale), un'idea meno buona in relazione alle API. Il processo di firma in se stesso è causa di confusione, per la necessità di normalizzare i parametri (ad esempio, normalizzare l'ordinamento, gestire le sequenze di escape e così via): un elemento causa di grande frustrazione per gli sviluppatori, dato che le risorse client e server forniscono spesso interpretazioni diverse della modalità di applicazione delle firme. Certamente esistono librerie che possono aiutare, ma un problema più ampio è rappresentato dal fatto che il requisito della firma limita la capacità degli sviluppatori di testare le transazioni utilizzando semplici utilità della riga di comando come curl. Molta parte del fascino dello stile RESTful rispetto all'utilizzo di alternative come i servizi web SOAP risiede nel fatto che il primo non richiede strumenti speciali per la codifica. Il funzionamento delle firme OAuth è in contrasto con questo vantaggio.

7 7 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione La specifica precedente aveva anche una visione limitata dei tipi di client. Nel caso di utilizzo "a tre gambe", il più immediato, il client era solito un'applicazione web. Tuttavia, gli sviluppatori desideravano sempre di più utilizzare OAuth in app in esecuzione all'interno di un browser o in app autonome in esecuzione su device mobile, come cellulari o tablet. Questo è possibile con OAuth 1.0, ma l'user experience ne risente, perché può essere necessaria una scomoda operazione di copia e incolla tra browser e app. OAuth 2.0 tenta di generalizzare l'implementazione OAuth originale per semplificare lo sviluppo client, migliorare l'user experience complessiva e scalare le implementazioni OAuth. Questo ha richiesto modifiche significative, non compatibili con le precedenti versioni. La nuova specifica separa esplicitamente i ruoli di autorizzazione dal controllo degli accessi. Oggi, il server di autorizzazione è nettamente separato dal server delle risorse. Oltre alla segregazione logica dei ruoli, questo favorisce anche l'uso di un server di autorizzazione centrale e la distribuzione di più server di risorse, analogamente a una classica architettura SSO. Un server di autorizzazione OAuth 2.0 è, in effetti, l'equivalente RESTful di un servizio token di sicurezza (STS). Figura 3. OAuth 2.0 distingue chiaramente tra server di autorizzazione e server delle risorse e definisce in maggiore dettaglio i flussi che descrivono l'acquisizione del token. Acquisizione token Client Authorization Server Proprietario della risorsa Resource Server Utilizzo del token OAuth 2.0 tenta di supportare tre profili client: app web tradizionali; app basate all'interno di un user-agent (cioè, un browser); app native (ad esempio un app per telefono cellulare, un decodificatore o perfino una console di gioco). Ognuno di questi elementi può avere capacità diverse in termini di interazione tra titolari delle risorse, server di autorizzazione e risorse protette. Inoltre, ciascuno può essere soggetto a requisiti di sicurezza diversi. La specifica descrive una serie di nuove attribuzioni di autorizzazione per soddisfare queste diverse esigenze; queste attribuzioni descrivono un processo mediante il quale un client può acquisire l'accesso autorizzato a una risorsa, ad esempio: Codice di autorizzazione - Questa attribuzione descrive il tipico scenario a tre gambe, in cui il client è un'app web come Twitter; esso utilizza un codice di autorizzazione intermedio per delegare in modo sicuro l'autorizzazione da un server di autorizzazione a un client, tramite lo user agent del titolare della risorsa (browser). Ha il vantaggio che le credenziali del titolare di una risorsa non vengono mai condivise con il client, né il token di accesso viene condiviso con lo user agent del titolare della risorsa, evitando rischi di hijacking.

8 8 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Implicita - Un'attribuzione leggermente più semplice, maggiormente adatta per le app in esecuzione all'interno di un user agent, come quelle JavaScript. Il client acquisisce direttamente un token di accesso dal server di autorizzazione. Questo elimina gran parte della complessità collegata al codice di autorizzazione intermedio, ma presenta uno svantaggio: il titolare della risorsa può potenzialmente ottenere il token di accesso. Credenziali password del titolare della risorsa - In questa attribuzione, il titolare della risorsa condivide le credenziali direttamente con il client, che le utilizza per ottenere un token di accesso direttamente, in un'unica transazione. Le credenziali non vengono conservate, in quanto il client utilizza il token di accesso per tutte le successive interazioni con le risorse protette. Si tratta di un flusso molto semplice, ma che esige una relazione di trust tra titolare della risorsa e client. Credenziali del client - In questo flusso, il client utilizza le proprie credenziali per accedere a una risorsa. In questo modo vengono sfruttate appieno i diritti esistenti del client. In aggiunta a queste attribuzioni, è presente un meccanismo di estensibilità per gestire altre forme di autorizzazione. Esiste ad esempio una specifica di token "al portatore" SAML che descrive l'utilizzo dei token SAML come mezzo per acquisire token di accesso OAuth. Questo è molto importante perché rappresenta un collegamento tra la classica infrastruttura SSO del browser e le moderne API. I token sono cambiati in OAuth 2.0, per supportare meglio la gestione delle sessioni. In passato, i token di accesso erano molto longevi (fino ad un anno) o, come nel caso di Twitter, avevano una durata illimitata. OAuth 2.0 introduce il concetto di token di breve durata e di autorizzazioni di lunga durata. I server di autorizzazione ora rilasciano token di aggiornamento del client. Si tratta di token longevi utilizzabili più volte da un client per acquisire token di accesso di breve durata. Uno dei vantaggi di questo approccio è che i titolari delle risorse o i responsabili della sicurezza, all'occorrenza, possono facilmente bloccare l'acquisizione di nuovi token da parte dei client. Le firme token sono ora facoltative. Di preferenza vengono utilizzati semplici token "al portatore" (il token viene utilizzato direttamente per ottenere l'accesso ed è considerato segreto), protetti da SSL. Questo approccio risulta molto più semplice rispetto all'elaborazione delle firme, che continua comunque a esistere in forma semplificata per supportare le transazioni non SSL. In cosa consiste la complessità di OAuth? Costruire un semplice proof-of-concept OAuth non è complesso; esistono librerie in quasi tutte le lingue principali che possono semplificare la sfida rappresentata dall'hard coding di una demo OAuth end-to-end. Tuttavia, l'implementazione OAuth in scala, laddove il volume delle transazioni, il numero di API da tutelare e il numero di client diversi contribuiscono tutti alla scala in questione, rimane una sfida notevole per qualsiasi gruppo di sviluppo e operazioni. Ma OAuth 2.0 è anche un facile bersaglio. La specifica 1.0a risolto un problema, e lo ha risolto bene. Ma la portata più ampia e la generalizzazione della nuova specifica hanno creato ambiguità notevoli, che rendono l'interoperabilità estremamente impegnativa. Ecco perché molte app di social networking, i principali sostenitori di OAuth, continuano a utilizzare la specifica 1.0, in attesa che la situazione si stabilizzi. L'apertura dei formati di token illustra bene questo scenario. Mentre, da un lato, questo ha notevolmente semplificato il processo di firma, che nelle specifiche precedenti rappresentava una sfida per gli sviluppatori, ha anche introdotto la possibilità di incapsulare token diversi (come SAML), aprendo opportunità per lo sfruttamento degli investimenti esistenti, ma anche creando notevoli sfide a livello di interoperabilità.

9 9 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Il più grande errore che è possibile commettere con OAuth oggi è guardarlo in isolamento. OAuth è infatti una tendenza molto attraente, ma costituisce solo uno dei pezzi del puzzle del controllo degli accessi aziendale. L'autorizzazione non può essere controllata esclusivamente dal client; anche l'impresa ospita la risorsa protetta deve avere il controllo. Le implementazioni OAuth single-point raramente riconoscono questa strada a doppio senso: ma la fiducia e il controllo reciproco sono essenziali per l'azienda. OAuth deve essere una parte del sistema di controllo degli accessi generale, basato su policy, per le API aziendali, non semplicemente una soluzione autonoma. Il controllo degli accessi basato su policy fornisce ad entrambe le parti un controllo sull'accesso, incorporando controlli come limitazioni time-of-day e white/black list basate su IP. Esso individua e neutralizza minacce come SQL Injection e attacchi Cross-Site Scripting (XSS). Convalida il contenuto di parametri e messaggi (compresi JSON o XML) rispetto a valori accettabili. Si integra completamente con i sistemi di controllo aziendali, consentendo ai fornitori di risorse di sapere esattamente chi accede a cosa e quando. E, infine, un sofisticato controllo degli accessi basato su policy consente di gestire gli SLA modellando le comunicazioni di rete, indirizzando le transazioni ai server disponibili ed eseguendo il throttling del traffico in eccesso prima che possa influenzare l'user experience o mettere a rischio i server. L'impresa non prenderebbe mai in considerazione di costruire la propria infrastruttura IAM per il proprio website: architetti e sviluppatori sanno che questo comporta molto di più della semplice autenticazione HTTP di base. OAuth è simile: apparentemente semplice ma, in ultima analisi, parte di un processo globale di autorizzazione molto complesso. In che modo CA Layer 7 facilita l'implementazione di OAuth? CA Layer 7 fornisce una soluzione completa e chiavi in mano per implementazioni OAuth 1.0a e OAuth 2.0. OAuth è incluso all'interno del sofisticato motore di controllo degli accessi basato su policy di API Proxy, SOA Gateway e Mobile Access Gateway di CA Layer 7. Un approccio OAuth veramente "in scala", in grado di gestire decine di migliaia di transazioni al secondo su un'unica istanza gateway. Questi gateway possono essere distribuiti come appliance hardware o immagini virtualizzate a basso costo. Entrambi i fattori di forma apportano un'infrastruttura di sicurezza di qualità militare all'oauth aziendale, incorporando in un unico pacchetto moduli crittografici con certificazione FIPS, rilevazione delle minacce avanzata, gestione del traffico SLA e controllo degli accessi granulare. Sarà come avere una guardia alla porta... anziché semplicemente una serratura. I gateway di CA Layer 7 possono essere implementati sia come server di autorizzazione (AS) che come server di risorse protette (RS). Entrambi gli elementi architettonici possono essere combinati in una singola istanza Gateway, oppure possono essere separati, consentendo a un AS centralizzato di gestire più istanze RS distribuite, comeillustrato nella Figura 4. Dato che i gateway sono disponibili in entrambi i fattori di forma, hardware e appliance virtuale, supportano la più ampia gamma possibile di implementazioni. I gateway hardware sono disponibili con moduli di sicurezza hardware (HSM) on board, fornendo protezione chiave per gli ambienti più sicuri. Le appliance virtuali facilitano la distribuzione e possono essere eseguiti ovunque, dal desktop all'infrastruttura server più sofisticata.

10 10 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Figura 4. I gateway di CA Layer 7 semplificano l'implementazione di OAuth. Proprietario della risorsa (ovvero, l'utente) Client AS (Authorization È possibile combinare le funzionalità di AS e RS in un unico gateway oppure distribuirle all'interno della rete RS (Resource Rete aziendale Qual è il vantaggio di un toolkit OAuth? Il toolkit OAuth di CA Layer 7 utilizza modelli standardizzati progettati per funzionare out-of-the box nelle implementazioni tipiche di OAuth. L'utilizzo di questi modelli consente ai clienti di aggiungere robuste funzionalità OAuth alle API esistenti in pochi minuti, anziché giorni. La verità è che la soluzione "a taglia unica" promessa da tanti produttori raramente funziona bene al di fuori di un'opportunità green-field estremamente limitata. Ad esempio, nella maggior parte dei progetti reali sono già presenti sistemi di identità cui è necessario accedere, o un'infrastruttura PKI con cui integrarsi. Nel nostro settore, siamo decisamente capaci a livello di integrazione dei dati e delle applicazioni: ma l'integrazione della sicurezza resta una sfida. Per affrontare meglio queste problematiche di integrazione, CA Layer 7 fornisce inoltre i componenti OAuth di base, dalla crittografia alla standardizzazione dei parametri alla gestione delle sessioni. Sono gli stessi componenti di base utilizzati nella nostra soluzione completa chiavi in mano, che riemergono però sotto forma di elementi completamente configurabili all'interno di una politica di controllo degli accessi. Questo consente ad architetti e sviluppatori di ottimizzare le loro implementazioni OAuth per soddisfare praticamente qualsiasi sfida si trovino ad affrontare. La personalizzazione della procedura di consenso OAuth è un altro ambito che beneficia notevolmente dell'apertura dei modelli di CA Layer 7, amplificata dalla potenza di un toolkit flessibile e aperto. Impostare il trust iniziale è una parte fondamentale dell'intero processo OAuth. CA Layer 7 consente di personalizzare completamente questo passaggio, per assicurare che si integri con l'infrastruttura di identità esistente e soddisfi i requisiti di conformità aziendali.

11 11 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione In che modo CA Layer 7 semplifica le cose nei casi d'uso di OAuth a due o tre gambe? I gateway di CA Layer 7 possono fornire sia servizi di autorizzazione endpoint che controllo degli accessi per i servizi protetti. Queste due funzioni possono coesistere in un unico gateway, oppure possono essere disgiunte. Il vantaggio della separazione è relativo alla scalabilità, alla ridondanza e alla distribuzione geografica dei servizi. Consente inoltre l'allineamento rispetto ai casi di business, ad esempio la separazione fisica delle API aziendali rispetto a quelle pubbliche. La maggior parte delle organizzazioni devono proteggere un numero elevato di API, spesso provenienti da una serie di luoghi diversi. In questi casi, ha senso distribuire gateway CA Layer 7 centralizzati come server di autorizzazione (spesso in un cluster, a scopo di ridondanza), e cluster remoti di gateway per proteggere le istanze API specifiche. Entrambi i modelli di distribuzione possono gestire contemporaneamente le versioni di OAuth 1.0a e 2.0. Questo modello funziona anche per entrambi gli scenari classici a due e a tre gambe, nonché per il modello di attribuzione OAuth 2.0, comprese attribuzioni di estensione come il token al portatore SAML. Queste distribuzioni sono illustrate nelle Figure 5 e 6. Figura 5. Distribuzione tipica per il classico scenario a due gambe o per attribuzioni come credenziali del titolare delle risorse e credenziali client. Distribuzione di CA Layer 7 in due fasi 1 firewall 2 firewall AS (Authorization Infrastruttura di identità Figura 6. Proprietario della risorsa Client Utilità di gestione dei carichi RS (Resource RS protetto (API sicure) Tipici scenari di distribuzione a tre gambe e attribuzione del codice di autorizzazione, nonché tipi di attribuzione impliciti. Si noti che i gateway di CA Layer 7 sono in grado di supportare simultaneamente tutte le versioni di OAuth, nonché mapping personalizzati per gestire eventuali problemi di interoperabilità. Proprietario della risorsa Client Distribuzione di CA Layer 7 in tre fasi 1 firewall 2 firewall AS (Authorization Utilità di gestione dei carichi RS (Resource RS protetto (API sicure) Infrastruttura di identità

12 12 White Paper: Semplificare l'implementazione di OAuth per l'organizzazione Contattare CA Technologies CA Technologies è a vostra disposizione per domande, commenti e feedback. Per maggiori informazioni contattare il rappresentante CA Technologies di riferimento o collegarsi all'indirizzo /security È possibile entrare in contatto con CA Technologies collegandosi al sito Agility made possible: il vantaggio di CA Technologies CA Technologies (NASDAQ: CA) fornisce soluzioni di gestione IT che aiutano i clienti nella gestione e nella protezione di ambienti IT complessi a supporto di servizi aziendali agili. Le organizzazioni utilizzano il software e le soluzioni SaaS di CA Technologies per accelerare l'innovazione, trasformare l'infrastruttura e proteggere dati e identità, dal data center al cloud. CA Technologies è impegnata a garantire che i suoi clienti ottengano i risultati attesi e il business value previsto, attraverso l'utilizzo della tecnologia dell azienda. Per ulteriori informazioni sui programmi a supporto dei nostri clienti visitare /customer-success. Per ulteriori informazioni su CA Technologies visitare. Copyright 2014 CA Layer 7, una società di CA Technologies. Contenuti riservati. Tutti i diritti riservati.