Windows Azure: Autenticazione di Windows Azure con ADFS

L'esigenza per un accesso ovunque e in qualsiasi momento ai dati aziendali richiede più livelli di autenticazione remota.

Dan Griffin e Tom Jones

Dirigenti esperti utilizzano mobili e cloud computing come un asset strategico per aumentare la velocità e la flessibilità dei loro processi decisionali. Dispositivi mobili già hanno dimostrato il loro valore nel business. Gli utenti hanno ovunque, in qualsiasi momento accedere ai dati di che cui hanno bisogno per rimanere produttivi.

La proliferazione di smartphone e tablet computer — per non parlare della domanda per il cloud computing — ha aumentato la pressione sui reparti IT di fornire accesso mobile sicuro al contenuto prezioso aziendale. In breve, se si non investire in formale e supporto per secure computing mobile, può essere sicuro che i concorrenti sono. Lo rendono un elemento di differenziazione.

Qualsiasi investimento interno in mobile computing deve tenere conto per la sicurezza dei dati. È inoltre necessario pianificare il costo potenziale di soddisfazione dell'utente che possono incorrere in problemi legati alla protezione. Per esempio, c'è stato a lungo un desiderio per un meccanismo unificato che autenticare in modo sicuro sia locali sia gli utenti remoti. Questo include dispositivi palmari, dispositivi desktop e applicazioni nuove e preesistenti.

Soluzioni di gestione flessibile e conveniente e identità sono state difficili da trovare. Gli utenti ottenere infastiditi alle richieste per un'altra credenziale di accesso. Inoltre, quando l'utente ha le credenziali di accesso stesso archiviate in più siti, aumenta il rischio di furto di identità o la divulgazione accidentale.

La buona notizia per esso è che il mobile computing è un chiaro esempio di sicurezza come un attivatore di affari. Inoltre, le tecnologie di autorizzazione e autenticazione più recente possono fare vera sicurezza senza soluzione di continuità per l'utente.

Alla conferenza RSA 2013, mobilità missione manager di Uniti Stati National Security Agency ha spiegato perché anche gli ambienti più sensibili per la sicurezza richiedono supporto coesivo per il guerriero della strada. I reparti IT devono abilitare servizi e dispositivi che supportano una varietà di meccanismi di autenticazione dell'utente.

È possibile adattare una soluzione di gestione delle identità esistenti come Microsoft Active Directory Federation Services (ADFS) per un'applicazione tipica line-of-business (LOB) Web in esecuzione nell'ambiente di cloud Windows Azure. Si può anche facilmente applicare la forma generale della soluzione descritta qui ad altre soluzioni di gestione delle identità, applicazioni e servizi cloud.

Metodi di autenticazione esistente

All'interno di Windows, servizi di Directory è sempre stato tradizionale repository per le identità utente impresa. Questo è stato progettato per dare accesso dipendenti alle risorse della rete dietro un firewall dove Kerberos è il protocollo di dominare.

Perché Kerberos non è raccomandato per l'uso su Internet, la maggior parte delle organizzazioni utilizzano protocolli di autenticazione basati su Web come Security Assertion Markup Language (SAML), Simple Web Token (SWT) e JSON Web Token (JWT). Questi token Web più recenti non sono ancora alloggiati dalla maggior parte dei servizi di directory aziendali, quindi avrete bisogno di un ulteriore servizio — chiamato il Server (token di protezione) — per collegare la directory tradizionale per le applicazioni Web più recenti.

Separazione dei ruoli è importante. Ogni server di applicazioni LOB non dovrebbe anche essere responsabile per l'autenticazione dell'utente. Ha bisogno di quello che il server di applicazione è la possibilità di contare su qualche altro servizio per fare il sollevamento di carichi pesanti di fornire informazioni di identità e l'autorizzazione in modo flessibile. Questo è ciò che è generalmente indicato come "identità federata".

Federazione significa che il server di applicazione (relying party o RP) stabilisce una relazione di trust con il provider di identità. Deve capire come valutare i metadati di identità utente fornito sotto forma di crediti.

Ad esempio, immaginare un utente tenta di accedere a contenuti su un servizio di rete (vedere Figura 1). RP richiede un insieme di attestazioni indirizzato da un'applicazione (ad esempio, il Web browser) sul dispositivo utente a uno o più servizi token. L'utente si autentica per la STS con qualunque credenziale è stato fornito: password, smart card e così via. La connessione diretta tra il RP e la STS è la configurazione iniziale in cui è stabilito il trust tra i due (in genere, è necessario configurare ciascuno con il certificato del server di altro).

When a user requests secure content, that request kicks off a series of cross-checks.

Figura 1 quando un utente richiede un contenuto protetto, tale richiesta prende il via una serie di controlli incrociati.

ADFS e Windows Azure nel mondo reale

Un'opzione è configurare ADFS come il STS. ADFS protegge l'interno servizi Active Directory Domain (AD DS) da attacchi esterni accettando le richieste di autenticazione da Internet. ADFS traduce l'identità basata su Active Directory in un formato Internet-friendly.

In questo caso, il dispositivo esterno è un tablet Windows. Il dispositivo è comunicare su una connessione di rete esterna a un server di applicazioni Web (RP) ospitato nel cloud di Windows Azure. L'application server deve conoscere l'utente autenticato da ADFS è utilizzando un computer che è compatibile con i criteri di rete.

Come sicurezza esperto Butler Lampson ha detto per anni, "tutti i trust è locali". In altre parole, il RP deve essere in grado di eseguire la propria convalida crediti prima che esso può autorizzare l'accesso al contenuto dell'applicazione. Che autorizzazione e la convalida è basato sull'utente identità e dispositivo compliancy attestazioni emesso da un STS. Il dispositivo dell'utente quindi unità quello scambio di dati di autenticazione (vedi Figura 2).

It takes a series of claim responses to validate a data request. 

Figura 2 prende una serie di risposte di reclamo per convalidare una richiesta dati.

Un agente sul dispositivo raccoglie le attestazioni da una varietà di fonti e li combina in una risposta all'application server. Che risposta deve soddisfare tutti i criteri per consentire l'accesso ai dati protetti. Attestazioni di identità utente e dispositivo-salute-conformità attestazioni possono provenire da diversi servizi token, come raffigurato Figura 2, o da una singola STS con molteplici fonti di metadati crediti (ad esempio, Active Directory e Microsoft System Center Configuration Manager).

È possibile modificare la miscela di provider di identità e di attributo per soddisfare le esigenze del servizio Web di RP. Ad esempio, si potrebbe combinare l'autenticazione di Office 365 con misurazioni dispositivo client per soddisfare criteri di prevenzione di perdita dei dati. In tutti i casi, la richiesta RP andrà a un agente utente nel dispositivo dell'utente. Che eseguirà il marshalling le attestazioni provenienti da fonti diverse per soddisfare le esigenze di RP.

Molti scenari di autenticazione Web lasciate le attestazioni di cache del dispositivo utente per un uso successivo. Questo è spesso chiamato uno scenario "Keep Me firmato In". Il RP ha anche la possibilità di richiedere ulteriori rivendicazioni da parte dell'utente come necessario dalla transazione richiesta dall'utente. Questo è noto come "step up" di autorizzazione.

Supporto ADFS e identità

Per gli sviluppatori di applicazioni LOB basato su Windows, supporto di federazione è costruito in Microsoft .NET Framework 4.5. Gli sviluppatori non devono diventare esperti di sicurezza al fine di abilitare scenari descritti qui.

Mentre il .NET Framework 4.5 non spedire con SWT e supporto JWT, aggiunta di queste strutture è ben documentato. Microsoft ha rilasciato un gestore JWT per il .NET Framework 4.5. Windows Server 2012 arriva con AD FS 2.1 un ruolo del server integrato che supporta ora il pool di applicazioni .NET Framework 4. Avrete bisogno di questo per sostenere il gestore JWT e altre funzionalità avanzate.

Claims-based access control è utile quando la partnership attraverso i confini aziendali perché esso separa l'autenticazione (ad esempio in Active Directory locale) dall'autorizzazione (ad esempio, ai servizi di dati condivisi nel cloud). Attestazioni semplificano il controllo dell'accesso basato sui ruoli amministrare perché ADFS e altri provider di identità può rilasciare attestazioni che supportano una varietà di autorizzazione verifica presso la RP.

In questo articolo viene illustrato come utilizzare crediti per abilitare l'autenticazione utente protetto da un'ampia varietà di dispositivi. Gli utenti ormai si aspettano sempre e ovunque accesso alle risorse dell'organizzazione. È obbligato a eseguire un delicato esercizio di equilibrismo.

È necessario abilitare il business con infrastruttura scalabile che supporta il mobile computing. Allo stesso tempo, è necessario proteggere il business con i meccanismi di sicurezza dei dati che sono gestibili e minimamente invasivo.

Tom Jones

Tom Jones è stato il Presidente fondatore della sottocommissione American National Standards ASC X9A10 per i pagamenti elettronici. Ha lavorato all'interno della Comunità di servizi finanziari con più organizzazioni tra cui Electronic Data Interchange (EDI X 12) e Accredited Standards Committee X 9 Inc. sui pagamenti elettronici, così come con la prima Data Corp., Intel Corp. e Microsoft.

 

Dan Griffin

Dan Griffin è il fondatore di JW Secure Inc. e un sicurezza di Enterprise di Microsoft MVP. Egli è l'autore dei libri "Cloud Security and Control" (CreateSpace Independent Publishing Platform, 2012) e "I quattro pilastri di Endpoint Security," che sarà pubblicato nel 2013. Egli è anche un oratore frequenti conferenze.

Contenuti correlati