Semplificare l'implementazione di OAuth per l'azienda

Guida pratica di OAuth e sicurezza delle API

WHITE PAPER | NOvembre 2014

ca.com/it

Sommario

2 | White PAPer: SemPlificAre l'imPlemeNtAziONe di OAuth Per l'OrgANizzAziONe

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 API Gateway semplifica l'implementazione di OAuth? 9

Qual è il vantaggio di un toolkit OAuth? 10

In che modo CA API Gateway è utile nei casi d'uso di OAuth two o three-legged? 11

Contattare CA Technologies 12

ca.com/it3 | White PAPer: SemPlificAre l'imPlemeNtAziONe di OAuth Per l'OrgANizzAziONe

Descrizione di OAuthOAuth 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 che nascondeva un rischio inaccettabile per la sicurezza. Al contrario, 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 può porvi fine facilmente in qualsiasi momento. uno dei grandi vantaggi che OAuth apporta alla community 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 assicurative, 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 aziende 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.

È tuttavia 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 technologies è fornire l'infrastruttura alle app aziendali compatibili con OAuth. Offriamo soluzioni drop-in che si integrano completamente con gli investimenti esistenti sulla tecnologia iAm per la gestione delle identità e dell'accesso in modo da fornire un modello di autorizzazione coerente in tutta l'azienda. tutte le soluzioni cA APi gateway sono disponibili come immagini virtuali di facile implementazione. cA technologies 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 technologies illustra il concetto di OAuth e come realizzarlo con semplicità all'interno della propria azienda.

ca.com/it4 | White PAPer: SemPlificAre l'imPlemeNtAziONe di OAuth Per l'OrgANizzAziONe

Un semplice esempio di OAuthil 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 altri utenti, probabilmente anche voi avrete 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, probabilmente sarebbe 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 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 A.

I tweet di Twitter anche sulla bacheca di Facebook

Client

Proprietario della risorsa

(alias l'utente)

1. L'utente pubblica un nuovo tweet

2. Twitter pubblica i tweet su Facebook a nome dell'utente

Server di autorizzazione (AS) Server della

risorsa (RS)

Figura A.

OAuth consente a twitter di inviare tweet all'account facebook dell'utente, senza utilizzare la password di facebook.

ca.com/it5 | 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 b. 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.

Per l'utente si tratta di un processo semplice e intuitivo e, infatti, questo rappresenta molta parte del fascino di OAuth. Questa apparente semplicità nasconde un'interazione molto più complessa tra i siti, spesso chiamata la "danza" di OAuth. three-legged OAuth è la definizione informale dello scenario descritto qui, che rappresenta il caso d'uso più tipico della specifica OAuth 1.0a, attualmente pubblicata come rfc 5849.

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 operations 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 tratta 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ù generalizzato 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.

1. Nessuna autorizzazione per la pubblicazione su Facebook

2. Eseguire l'accesso a Facebook per consentire a Twitter di pubblicare in bacheca

3. Autorizzazione concessa per pubblicare su Facebook

Figura B.

in che modo un utente autorizza twitter a inviare tweet sulla propria bacheca di facebook.

ca.com/it6 | 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 affrontato da OAuth. i suoi designer hanno considerato le alternative e hanno prodotto soltanto un numero limitato di soluzioni, 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 operations 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.

Open id connect ha tentato di fornire un sign-on web unico. in un mondo perfetto, dove Open id connect fosse universale, OAuth non sarebbe probabilmente mai stato necessario. Nonostante il successo ottenuto su siti autorevoli come Yahoo e WordPress, Open id connect non è tuttavia mai stato adottato su larga scala. Può comunque avere una seconda possibilità di successo per il modo in cui completano il protocollo 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.

ca.com/it7 | 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 three-legged, il più immediato, il client era di 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 la 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).

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 three-legged, 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.

Client

Proprietario della risorsa

Server di autorizzazione

Server della risorsa

Acquisizionetoken

Utilizzotoken

Figura C.

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.

ca.com/it8 | 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 principali lingue 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 operations.

OAuth 2.0 è tuttavia anche un facile bersaglio. la specifica 1.0a risolto un problema, e lo ha risolto bene. la portata più ampia e la generalizzazione della nuova specifica hanno creato tuttavia 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à.

ca.com/it9 | 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 API Gateway aiuta l'implementazione di OAuth?cA technologies fornisce una soluzione completa e chiavi in mano per implementazioni OAuth 1.0a e OAuth 2.0. il protocollo OAuth è incluso nel sofisticato motore di controllo degli accessi basato su policy in cA APi gateway. 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 APi di cA technologies possono essere implementati sia sui server di autorizzazioni (AS) sia sui server di risorse (rS) protetti. entrambi gli elementi architettonici possono essere combinati in una singola istanza di gateway, oppure possono essere separati, consentendo a un server AS centralizzato di gestire più istanze rS distribuite, come illustrato nella figura d.

dato che i cA APi 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 il deployment e possono essere eseguiti ovunque, dal desktop all'infrastruttura server più sofisticata.

ca.com/it10 | White PAPer: SemPlificAre l'imPlemeNtAziONe di OAuth Per l'OrgANizzAziONe

Qual è il vantaggio di un toolkit OAuth?il toolkit OAuth di cA APi gateway 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à del toolkit OAuth alle APi esistenti in pochi minuti, anziché in 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 APi gateway fornisce inoltre i componenti del toolkit 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. Architetti e sviluppatori possono quindi ottimizzare le loro implementazioni del toolkit OAuth per soddisfare praticamente qualsiasi sfida si trovino ad affrontare.

la personalizzazione della procedura di consenso del toolkit OAuth è un altro ambito che si avvantaggia notevolmente dell'apertura dei modelli di gateway, amplificata dalla potenza di un toolkit flessibile e aperto. impostare il trust iniziale è una parte fondamentale dell'intero processo del toolkit OAuth. cA APi gateway consente di personalizzare completamente questo passaggio, per assicurare che si integri con l'infrastruttura di identità esistente e soddisfi i requisiti di conformità aziendali.

Client

Proprietario della risorsa (alias l'utente)

Server di autorizzazione (AS)

Server della risorsa (RS)

Rete aziendale

Le funzioni AS e RS possono essere combinate in un unico gateway o distribuite sulla rete

CA APIGateway

CA APIGateway

Figura D.

i gateway APi di cA technologies semplificano l'implementazione di OAuth.

ca.com/it11 | White PAPer: SemPlificAre l'imPlemeNtAziONe di OAuth Per l'OrgANizzAziONe

In che modo CA Technologies è utile nei casi d'uso di OAuth two o three-legged?cA APi gateway può 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 aziende devono proteggere un numero elevato di APi, spesso provenienti da una serie di luoghi diversi. in questi casi, ha senso distribuire i gateway APi centralizzati di cA technologies 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 deployment possono gestire contemporaneamente le versioni di OAuth 1.0a e 2.0. Questo modello funziona anche per entrambi gli scenari classici two o three-legged, nonché per il modello di attribuzione OAuth 2.0, comprese attribuzioni di estensione come il token al portatore SAml. Questi deployment sono illustrati nelle figure e e f.

Two-Legged Deployment di CA Technologies

Proprietario della risorsa

Client

Firewall 1 Firewall 2

Utilità di bilanciamento

dei carichiServer della risorsa (RS)

Server di autorizzazione (AS)

Server delle risorse protette (API sicure)

Infrastruttura delle identità

CA APIGateway

CA APIGateway

Three-Legged Deployment di CA Technologies

Proprietario della risorsa

Firewall 1 Firewall 2

Utilità di bilanciamento

dei carichiServer della risorsa (RS)

Server di autorizzazione (AS)

Server delle risorse protette (API sicure)

Infrastruttura delle identità

Client

CA APIGateway

CA APIGateway

Figura E.

deployment tipico per il classico scenario two-legged o per attribuzioni come credenziali del titolare delle risorse e credenziali client.

Figura F.

tipici scenari di three-legged deployment e attribuzione del codice di autorizzazione, nonché tipi di attribuzione impliciti. Si noti che cA APi gateway è in grado di supportare simultaneamente tutte le versioni di OAuth, nonché i mapping personalizzati per gestire eventuali problemi di interoperabilità.

È possibile entrare in contatto con CA Technologies collegandosi al sito ca.com/it

cA technologies (NASdAQ: cA) crea software che promuove l'innovazione all'interno delle aziende, consentendo loro di sfruttare le opportunità offerte dall'economia delle app. il software rappresenta il cuore di qualsiasi business, in ogni settore. dalla pianificazione allo sviluppo, fino alla gestione e alla sicurezza, cA technologies lavora con le aziende di tutto il mondo per cambiare il nostro modo di vivere, interagire e comunicare, in ambienti mobili, cloud pubblici e privati, distribuiti e mainframe. Per ulteriori informazioni, visitare il sito ca.com/it.

12 | White PAPer: SemPlificAre l'imPlemeNtAziONe di OAuth Per l'OrgANizzAziONe

copyright © 2014 cA technologies. contenuti riservati. tutti i diritti riservati. cS200-87200_1114

Contattare CA TechnologiescA technologies è a vostra disposizione per domande, commenti e feedback. Per maggiori informazioni contattare il rappresentante cA technologies di riferimento o visitare www.ca.com/it/api