Articolo
03/22/2015

Il presente articolo è stato tradotto automaticamente.

Azure Insider

BYOD sfida: Connessione dispositivi portatili per l'azienda

Bruno Terkaly Esistono numerosi problemi che circonda il movimento di portare il proprio dispositivo (BYOD) in ambienti aziendali e come consentire agli sviluppatori di servizi mobili di Azure. Un valore di base di servizi mobili è che democratizza l'identità e riduce il costo e l'impegno a fornire l'accesso protetto alle risorse aziendali protette. In questo articolo, che Effettueremo più approfondito i requisiti necessari per supportare scenari più complessi per la connessione di applicazioni per dispositivi mobili per le risorse dell'organizzazione.

Saranno iniziate definendo le parti interessate dell'identità e osservare le similitudini e differenze legate ai dipendenti, partner commerciali e clienti. Si esamineranno anche architetture software che forniscono una connettività sicura per gli utenti di dispositivi mobili l'accesso a siti e servizi on-premise e browser. Avanti in questo articolo verrà illustrata in queste tecniche utilizza un app iOS che si connette a un Mobile Services eseguire fine, come un endpoint di servizio locale.

Non tutti gli accessi sono uguali

Esistono diversi obiettivi importanti di questo impegno. Il primo consiste nel fornire accesso alle risorse locali con un minimo di codice personalizzato o variazioni di infrastruttura, comprese le configurazioni di rete esistente. Un altro obiettivo consiste nel gestire questi scenari di utilizzo per garantire il controllo e la visibilità, pur essendo agile e flessibile.

Non tutti gli utenti che devono accedere al firewall aziendale vengono creati uguali. E non tutti i dati protetti dal firewall aziendale deve essere lo stesso livello di protezione. Alcuni dipendenti devono maggiore accesso alle informazioni protette. Come campo rappresentanti necessitano di accedere alle informazioni più aggiornate sui prezzi dei prodotti e livelli di scorte. Sono anche potrebbe essere necessario accedere ai dati di accounting di clientela recenti acconti. Sono in genere, tuttavia, necessario l'accesso alle applicazioni di gestione del personale.

Partner commerciali hanno le proprie esigenze specifiche. I partner aziendali esterni spesso effettuerà la federazione identità su una rete extranet. Partner commerciali in genere di gestire la propria infrastruttura di identità per autenticare gli utenti e utilizzerà "crediti" per controllano l'accesso alle risorse protette della società. In questo modo, il partner o la società utilizzerà Criteri di attendibilità per eseguire il mapping di attestazioni in ingresso ai crediti compresi da una risorsa protetta, ad esempio un'applicazione Web interna.

Esistono due altri cointeressati identità meno comuni. I clienti devono spesso accedere alle informazioni di account, ad esempio PayPal o Netflix. Un prospect in modo efficace è un potenziale cliente. Egli potrebbe hanno fornito le informazioni della carta di credito, ma non è realmente acquistato nulla ancora. Tutti questi tipi di utenti condividono una caratteristica comune: Tutti desiderano portare e utilizzare loro iOS, i dispositivi Android e Windows Phone in azienda.

Gestione della protezione aziendale

Almeno cinque mazzetti software svolgono un ruolo nella protezione dei dispositivi portatili dell'organizzazione. In questo caso, questo articolo verrà fornita un'occhiata a connessioni ibrido, Bus di servizio di Azure, Proxy di applicazione Azure Active Directory e Microsoft Azure API di gestione.

È semplice avere dipendenti presentare le credenziali ad Active Directory tramite un'interfaccia utente Web, ottenere un accesso token e iniziare a lavorare, ma il mondo dell'identità è molto più perfezionati e complesse. Il concetto che "una adatta a qualsiasi" non è assolutamente vero. Dipendenti in genere sono obbligati a utilizzare un provider di identità aziendale.

La maggior parte delle imprese hanno portato identità interne, in genere sfruttando Active Directory, che espone principalmente un protocollo basato su LDAP. In questo nuovo mondo mobile, abilitato al cloud, imprese necessario un protocollo di comunicazione basato su HTTP per i dispositivi mobili. Microsoft ha creato un'identità di tale sistema in Azure chiamato Azure Active Directory (AD Azure). Una delle caratteristiche di Active Directory Azure è che le aziende possono sincronizzare identità al cloud utilizzando la sincronizzazione delle directory. Lettura informazioni su che elaborano alla bit.ly/1ztaB9Z.

Esistono un paio di altre funzionalità utili in Azure Active Directory. AD Azure offre la comodità del servizio single sign-on (SSO). In questo modo un dipendente di accedere alle risorse protette nel tempo senza ripetutamente dover accedere e fornire le credenziali. Il token di accesso viene memorizzato localmente come un cookie sul dispositivo del dipendente. È possibile limitare l'accesso utilizzando tecniche di scadenza del token.

Azure Active Directory supporta inoltre OAuth 2.0, forse il più diffuso standard aperto per l'autenticazione. Client sono disponibili applicazioni delegata accesso protetto alle risorse del server per conto di un proprietario della risorsa. Utilizza OAuth 2.0, AD Azure può autenticare un utente ed emettere token SAML 2.0 o JWT. Ulteriori informazioni sui funzionano del token in bit.ly/1pDc0rg.

Partner commerciali

Le società in modo tradizionale sono gestiti autenticazione all'interno di altro infrastrutture IT è stato tramite una relazione di trust federativa. Questo è necessario stabilire una relazione di trust tra i servizi di federazione delle due società (vedere Figura 1). Questo comportamento supportato transazioni basate sul Web protette con i partner commerciali. Tuttavia, non è così semplice come suoni e anzi può presentare particolari difficoltà.

Figura 1 modello di identità tradizionali per la federazione di Active Directory

Il partner è necessario impostare una relazione di trust tra loro Active Directory e Active Directory dell'organizzazione. Un dipendente da una società in questo modo l'autenticazione tramite la propria Active Directory e quindi scambiare i token di autenticazione con Active Directory della società per poter accedere a un'applicazione in altra rete. Questo approccio richiede una notevole quantità di coordinamento e flussi di lavoro manuale per gli amministratori IT.

Figura 2 illustra un approccio più moderno alla gestione delle identità. In genere, una copia dell'identità del dipendente sono ospitati in Azure, ma alcune identità può risiedere in Azure da solo. Manutenzione è ridotto al minimo, poiché la copia originale della maggior parte delle identità è gestito in locale. Un processo di sincronizzazione in background consente di mantenere la copia cloud di identità completamente sincronizzato. Gli utenti possono connettersi direttamente a Azure Active Directory in un centro dati nella cloud e ottenere quindi reindirizzati all'applicazione appropriata.

Figura 2 approccio moderno alla gestione delle identità

Per gli sviluppatori di applicazioni mobili, troverete una serie di librerie su GitHub, è possibile utilizzare per sfruttare i vantaggi di Active Directory Azure (bit.ly/1qmeipz).

Android, iOS, il.NET Framework di Microsoft, JavaScript, Node. js e così via sono tutti supportati. Ad esempio, l'esempio iOS viene illustrato come ottenere un codice di autorizzazione interattivo per lavorare con un account di lavoro. È possibile collegare l'account di lavoro a un server di Active Directory in esecuzione nel centro dati o live completamente nel cloud con Azure Active Directory. Sul back-end, è possibile utilizzare una API di Node. js e basato su REST o API Web .NET.

Accesso cliente

È in genere non considerare visualizzabile dal cliente siti e servizi di accesso alle risorse aziendali protetti. Tuttavia, è più comune di quanto si possa pensare. Ad esempio, Wells Fargo possibile esporre i dati finanziari di un cliente sul Web tramite un sito Web protetto o l'applicazione per dispositivi mobili, mentre Netflix potrebbe essere necessario fornire un accesso protetto alle risorse protette, ad esempio cronologia pagamento o il saldo di conto corrente. Questo diventa particolarmente importante per i clienti che utilizzano dispositivi mobili.

In alcuni scenari, è anche opportuno utilizzare i provider di identità sociali, ad esempio Account Microsoft, Facebook, Google o Twitter. Questo approccio è stato illustrato in dettaglio nell'articolo Azure Insider di novembre (msdn.microsoft.com/magazine/dn818496), in cui è scritto un'applicazione nativa iOS che utilizza Twitter come il provider di identità.

Il presupposto è che tutti gli utenti possono scaricare l'applicazione e accedere al sito Web. Non esiste un livello di servizio pubblico. Prospect in genere hanno un'esperienza non autenticata e vedere informazioni solo pubblicamente disponibili. Anche in questo caso, potrebbe essere necessità di accedere alle risorse locali. Il servizio potrebbe fornire un livello di servizio non autenticato o rispondere a un insieme di credenziali predefinite.

Proteggere gli strumenti di connettività

Identità a parte, sono disponibili diversi strumenti che consentono di connettersi in modo sicuro gli utenti alle risorse nelle reti aziendali. Un esempio è l'inoltro di Azure Service Bus (vedere Figura 3), che fornisce un modo elegante per facilitare l'accesso alle risorse protette. L'inoltro di Azure Service Bus può essere considerato come un servizio ospitato dal cloud che funge da gatekeeper al broker di connessione tra un client e risorse aziendali. L'inoltro del Bus di servizio viene autenticato e apre solo le porte in uscita. Supporta argomenti e code, nonché, in modo che è possibile implementare un tipo di messaggistica distribuite. Incorporare gli hub di eventi anche se è necessaria per l'acquisizione di grandi quantità di eventi.

Figura 3, l'inoltro del Bus di servizio Azure

Il vantaggio di questo approccio è che non sono presenti modifiche di configurazione necessarie per le reti locali. Che include provisioning di utenti o modificare le impostazioni di firewall, poiché il client e il servizio di back-end utilizzano connettività in uscita alla porta 80 o 443. In altre parole, ulteriori porte non devono essere aperte per il traffico in ingresso e nessun proxy è necessario.

Approccio del Proxy di applicazione

Il secondo approccio alla disponibilità di risorse protette all'esterno del firewall consiste nell'utilizzare il servizio Proxy di applicazione AD Azure, attualmente in anteprima. Ciò consente l'accesso protetto all'interno di applicazioni Web e servizi attraverso i protocolli HTTP e HTTPS Web di un'organizzazione.

Il grande vantaggio di questo approccio è gli utenti possono usufruire SSO e un'esperienza di applicazione nativa e continuare a utilizzare un dispositivo non gestito, non appartenenti a un dominio. In un articolo precedente, è stato illustrato il concetto di un "luogo di lavoro join," che è una versione leggera di un dispositivo di dominio completo (bit.ly/1tE7dRR). Vengono supportati gli scenari BYOD dove gli utenti desiderano mantenere il controllo dei propri dispositivi personali.

Proxy di applicazione AD Azure fornisce una stretta integrazione con Active Directory Azure, SSO, le applicazioni Software-as-a-Service e locali, registrazione a più fattori di autenticazione e il dispositivo di supporto. Il connettore bridge tra la risorsa per il proxy di applicazione e, pertanto, l'applicazione per dispositivi mobili. Questi connettori sono essenzialmente route ridondanza del traffico e di supporto, scala e più siti.

Un Proxy applicazione offre alcuni vantaggi. In primo luogo, è possibile implementare un controllo preciso a livello di applicazione, dispositivo, utente e percorso. Applicazioni client esistenti non richiedono la modifica e periferiche stesse non devono essere modificate. Supporta inoltre l'autenticazione a più fattori (AMF), che può fornire un ulteriore livello di protezione per le risorse riservate. AMF fornisce numerosi servizi di supporto, quali avvisi di frode, whitelists IP e il telefono cellulare o SMS come secondo fattore di autenticazione.

Il terzo vantaggio di un Proxy di applicazione è fornisce l'isolamento tra le reti cellulari e reti locali. Servizi back-end sono mai esposti direttamente perché il Proxy di applicazione si trova in Active Directory Azure e raggiunge il connettore direttamente dalla risorsa protetta. Infine, un Proxy applicazione protegge contro gli attacchi denial of service, dando controllare la limitazione, gestione di Accodamento messaggi e la sessione.

Gestione delle API

Un terzo approccio per l'accesso alle risorse protette è la gestione delle API di Azure, inoltre si comporta come un proxy per le risorse locali. Consente di esporre i servizi Web implementati all'interno del firewall al mondo esterno. Per correggere questa opzione, è necessario apportare alcune modifiche al server Web locale, nonché creare e configurare un'API nel portale Azure. È possibile creare le API con API Web .NET o Node. js.

In primo luogo, si vedrà l'autenticazione con Azure API di gestione, l'autenticazione di base per fornire l'accesso esterno a un server del sito Web basato su IIS locale. Il primo passo per l'attivazione di questo scenario è apportare alcune modifiche al server Web IIS locale e abilitare l'autenticazione di base. All'interno di IIS, è possibile scegliere l'icona di autorizzazione e drill-down l'autenticazione di base per aggiungere un utente. Azure Management API avranno accesso locale IIS con il profilo utente.

L'approccio successivo, che è possibile utilizzare con gestione API Azure è l'autenticazione con segreto condiviso. Ciò significa che il proxy di gestione API sarà necessario archiviare una chiave segreta. Tale chiave nell'intestazione HTTP inserirà prima di tentare di connettersi al servizio Web back-end locale. È non opportuno sorprende che il servizio di back-end Web sarà necessario estrarre la chiave segreta nell'intestazione HTTP e di elaborare la richiesta di autorizzazione.

È possibile implementare l'autenticazione con segreto condiviso per il portale di gestione di Azure, passando alla sezione di gestione delle API e selezionare i criteri del menu. In questo caso, si aggiungerà un criterio, non è altro che una chiave segreta inviata al server Web locale. File di definizione del criterio che verrà aggiunto è un documento XML.

Connessioni ibrido

Il quarto e probabilmente più semplice approccio per concedere l'accesso alle risorse protette utilizza connessioni ibrida (vedere Figura 4), una funzionalità dei servizi BizTalk Azure attualmente in anteprima. Connessioni ibrida sfrutta la tecnologia di inoltro del Bus di servizio per creare una connessione semplice, sicura ed efficace tra processo locale e un servizio di servizi mobili di Azure o un sito di siti Web di Azure. È possibile utilizzare connessioni ibrido per connettersi a qualsiasi risorsa locale che utilizza TCP o HTTP per la connessione, inclusi i database e soluzioni ERP come SQL, Oracle e SAP.

Figura 4 Microsoft Azure BizTalk Services, ovvero connessioni ibrido

Un requisito per questo è che il processo locale deve essere accessibile tramite una porta TCP statica, ad esempio SQL Server sulla porta 1433. È possibile utilizzare qualsiasi framework per connettersi alla risorsa, tra cui Node. js, Java o il.NET Framework. La maggior parte dei requisiti di configurazione dell'inoltro del Bus di servizio sono esclusi dalle connessioni ibrido. Non vengono apportate modifiche necessarie al codice sorgente del processo locale.

Per utilizzare connessioni ibrido, configurare una piccola quantità di metadati nel portale di gestione di Azure. Installare un agente sul server che ospita il processo (SQL Server, MySQL, il servizio Web e così via). Esiste una connessione di inoltro del Bus di servizio dietro le quinte, utilizzando un tasto SAS per l'autenticazione. È possibile ruotare le chiavi sul lato servizio e sul lato client in modo indipendente all'interno del portale. Poiché utilizza il servizio Bus di inoltro, nessun endpoint o il proxy in ingresso sono necessari.

Se si preferisce più semplicità del set di backup e attività di sviluppatore, connessioni ibrido potrebbe essere la soluzione. Ancora meglio, perché è disponibile nel livello libero di Azure BizTalk Services, è possibile utilizzarlo economico, pagando solo della larghezza di banda "egress".

Ora per una dimostrazione

Come previsto, a questo punto verrà illustrata in alcune delle tecniche qui descritte, utilizzando un nativo iOS app e sua MAS back-end come la piattaforma. Verrà aggiunto un servizio Web di locali e un locale SQL Server utilizzano connessioni ibrido. Ai fini di risparmiare spazio e utilizzo di risorse già esistenti, fare riferimento all'esercitazione del team di AMS al bit.ly/1mK1LQF. Nelle direzioni troverete diramazioni a ulteriori risorse tutorial (bit.ly/1vFiPuv e bit.ly/1xLWuuF) per compilare la soluzione completa, che è costituito dai seguenti componenti:

Indietro di un'API Web terminare installato come servizio AMS e registrato con un affittuario AD Azure
Un'applicazione nativa iOS registrati con affittuario AD Azure stesso
Collegamento bidirezionale nel tenant tra l'API Web e il servizio AMS

Esistono diversi passaggi che implicano la creazione di metadati nel portale di gestione di Azure, mentre in altri casi mediante strumenti di sviluppo nativo (Visual Studio, Xcode, Android e così via) per creare il file apps effettivo. Al termine, è necessario disporre di un sistema che richiede l'autenticazione nelle applicazioni iOS immettendo le credenziali AD Azure. Quindi sarà possibile eseguire le operazioni CRUD sui dati da fare. Aggiungere il codice in Figura 5 per il codice del servizio mobile.

Figura 5 Client codice utilizza risorse tramite una connessione ibrida protette

// Use the SQL Server connection
try
{
  SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder();
  builder["Data Source"] = "myserver";
  builder["Integrated Security"] = false;
  builder["Initial Catalog"] = "mydb";
  builder["User ID"] = "greg";
  builder["Password"] = "S3cr3t";
  int count = 0;
  string query = "SELECT COUNT(*) FROM mytable";
  using (SqlConnection conn = new SqlConnection(builder.ConnectionString))
  using (SqlCommand cmd = new SqlCommand(query, conn))
  {
    conn.Open();
    cmd.CommandType = System.Data.CommandType.Text;
    count = Convert.ToInt32(cmd.ExecuteScalar());
  }
  string results = string.Format("Count of records in mytable is {0}", 
    count);
  Services.Log.Info(results);
}
catch (Exception ex)
{
  Services.Log.Error(ex.Message);
}
// Use the Web service connection
try
{
  const string URL = "http://mydevbox:31106/";
  HttpClient client = new HttpClient();
  client.BaseAddress = new Uri(URL);
  client.DefaultRequestHeaders.Accept.Clear();
  client.DefaultRequestHeaders.Accept.Add(
  new MediaTypeWithQualityHeaderValue("application/json"));
  string response = await client.GetStringAsync("api/values/5");
  Services.Log.Info("Accessing the web service succeeded.");
}
catch (Exception ex)
{
  Services.Log.Error(ex.InnerException.Message);
}

Nella connessione di informazioni per SQL Server e di indirizzamento del servizio Web (un semplice modello di servizio Web), solo il nome della connessione ibrida sono coinvolto.

Conclusioni

Identità sta diventando sempre più importante nel mondo della BYOD. Le aziende sono sotto la crescente pressione per supportare dispositivi mobili nell'area di lavoro. È resa più complessa dal fatto che viviamo in un mondo ibrido. Risorse principali si trovano nella cloud e locali. L'autenticazione può verificarsi nel cloud e/o locale. Applicazioni aziendali, servizi in esecuzione in locale o ospitato nella cloud a servizi Web, potrebbero includere risorse protette. Con così tante variabili, è necessario più approcci flessibili.

Per informazioni dettagliate di questa implementazione, verifica Go Live sul post di blog Azure in bit.ly/1rVbtCpe per un Java-base trattamento dell'argomento, bit.ly/1zW7XpZ.

Greg Oliver unito l'organizzazione Microsoft Azure ISV nel 2010. Gran parte del suo tempo aiuta le aziende con i piani di migrazione e implementazioni. Più di recente, ha lavorato con una società di giochi più diffusi consumer con la migrazione da un provider di cloud concorrenti. Prima di entrare in Microsoft, è stato un partner tecnologico di una società di avvio.

Bruno Terkaly è un principal software engineer di Microsoft con l'obiettivo di consentire lo sviluppo dell'industria leader servizi e applicazioni su dispositivi. Egli è responsabile il cloud superiore e opportunità mobile tutti gli Stati Uniti e oltre dal punto di vista di soluzioni per la tecnologia. Aiuta i partner portare le applicazioni al mercato fornendo indicazioni architetturali e tecnica approfondite fidanzamento durante l'ISV valutazione, sviluppo e distribuzione. Inoltre lavora a stretto contatto con il cloud e mobili gruppi engineering, fornendo un feedback e che influenzano la Guida di orientamento.

Grazie al seguente esperto tecnico di Microsoft per la revisione di questo articolo: Santosh Chandwani