Guida pratica alla sicurezza OAuth e API con CA

Transcript

WHITE PAPER | febbraio 2014
Guida pratica alla sicurezza
OAuth e API con CA Layer 7
Semplificare l'implementazione di OAuth per l'organizzazione
2 | White Paper: Semplificare l'implementazione di OAuth per l'organizzazione
Sommario
ca.com/it
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
ca.com/it
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.
ca.com/it
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.
Come consentire i tweet sulla bacheca di Facebook
OAuth consente a Twitter
di inviare tweet
all'account Facebook
dell'utente, senza
utilizzare la password
di Facebook.
Client
1. L'utente posta
un nuovo tweet
Proprietario
della risorsa
(ovvero, l'utente)
2. Twitter posta i
tweet su Facebook
a nome dell'utente
AS
(Authorization
Server)
RS
(Resource
Server)
ca.com/it
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 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 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.
ca.com/it
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.
ca.com/it
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).
Acquisizione
token
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.
Authorization
Server
Client
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.
ca.com/it
• 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à.
ca.com/it
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.
Figura 4.
I gateway di CA Layer 7
semplificano
l'implementazione
di OAuth.
ca.com/it
Client
Proprietario della risorsa
(ovvero, l'utente)
AS (Authorization
Server)
È possibile combinare le funzionalità di
AS e RS in un unico gateway oppure
distribuirle all'interno della rete
RS (Resource
Server)
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.
ca.com/it
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 di CA Layer 7 in due fasi
Distribuzione tipica per il
classico scenario a due
gambe o per attribuzioni
come credenziali del
titolare delle risorse
e credenziali client.
1° firewall
2° firewall
AS (Authorization
Server)
Infrastruttura
di identità
Utilità di gestione
dei carichi
Proprietario
della risorsa
RS protetto
(API sicure)
RS (Resource
Server)
Client
Figura 6.
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à.
Distribuzione di CA Layer 7 in tre fasi
Client
1° firewall
2° firewall
AS (Authorization
Server)
Infrastruttura
di identità
Proprietario
della risorsa
Utilità di
gestione dei
carichi
RS (Resource
Server)
RS protetto
(API sicure)
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 ca.com/it/security
È possibile entrare in contatto con CA Technologies collegandosi al sito ca.com/it
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 ca.com/it/customer-success. Per ulteriori informazioni su
CA Technologies visitare ca.com/it.
Copyright © 2014 CA Layer 7, una società di CA Technologies. Contenuti riservati. Tutti i diritti riservati.