Condividi tramite


Panoramica di Enterprise Single Sign-On

È possibile che un processo di business basato su numerose applicazioni attraversi vari domini di sicurezza diversi. Il set di credenziali di sicurezza richiesto per l'accesso a un'applicazione in un sistema Microsoft Windows può infatti essere diverso da quello richiesto per l'accesso a un'applicazione in un mainframe IBM, ad esempio un nome utente RACF e una password. La gestione di questa moltitudine di credenziali risulta piuttosto difficile per gli utenti e può rappresentare una sfida ancora più ardua nel caso di processi automatizzati. Per risolvere questo problema, BizTalk Server include Enterprise Single Sign-On.

Enterprise Single Sign-On non è in realtà meccanismo che consente di utilizzare un unico account di accesso per tutte le applicazioni, ma piuttosto un sistema per mappare un ID utente di Windows a credenziali utente non Windows. Non consente di risolvere tutti i problemi di accesso aziendale di un'organizzazione, ma può semplificare le situazioni in cui i processi di business utilizzano applicazioni in sistemi diversi.

Creare un'applicazione di affiliazione per sistemi non Windows

Per utilizzare Enterprise Single Sign-On, un amministratore deve definire le applicazioni affiliate, ognuna delle quali rappresenta un sistema o un'applicazione non Windows. Un'applicazione affiliata può essere ad esempio un'applicazione CICS eseguita in un mainframe IBM, un sistema ERP SAP eseguito in Unix o qualsiasi altro tipo di software. Poiché dispone di un proprio meccanismo di autenticazione, ognuna di queste applicazioni richiede credenziali univoche.

Enterprise Single Sign-On archivia in un database SSO un mapping crittografato tra l'ID utente di Windows di un utente e le relative credenziali per una o più applicazioni affiliate. Quando l'utente deve accedere a un'applicazione affiliata, le relative credenziali possono essere ricercate nel database SSO da un server SSO (Single Sign-On). Nella figura seguente è illustrato questo meccanismo.

Diagramma che illustra come è possibile cercare le credenziali per un'applicazione nel database SSO da un server Single Sign-On (SSO).

In questo esempio un messaggio inviato da un'applicazione a BizTalk Server viene elaborato da un'orchestrazione e quindi inviato a un'applicazione affiliata eseguita in un mainframe IBM. La funzione di Enterprise Single Sign-On consiste nel verificare che vengano inviate le credenziali corrette (ovvero il nome utente e la password corretti) con il messaggio passato all'applicazione affiliata.

Elaborazione di messaggi con un ticket SSO

Come illustrato nella figura, quando un adapter di ricezione riceve un messaggio può richiedere un ticket SSO al server SSO A (passaggio 1). Il ticket crittografato contiene l'identità Windows dell'utente che ha effettuato la richiesta e un periodo di timeout. Non confonderlo con un ticket Kerberos, non è la stessa cosa. Dopo aver acquisito il ticket, viene aggiunto come proprietà al messaggio in ingresso. Il messaggio segue quindi il normale percorso attraverso il motore BizTalk Server. In questo esempio viene gestito da un'orchestrazione. Anche il messaggio in uscita generato dall'orchestrazione conterrà il ticket SSO acquisito in precedenza.

Questo nuovo messaggio è destinato all'applicazione eseguita in un mainframe IBM e deve quindi contenere le credenziali appropriate per l'accesso dell'utente a tale applicazione. Per ottenere queste credenziali, l'adapter di trasmissione contatta il server SSO B (passaggio 2) fornendo il messaggio appena ricevuto (contenente il ticket SSO) e il nome dell'applicazione affiliata per cui tenta di recuperare le credenziali. Tramite questa operazione, chiamata riscatto, il server SSO B convalida il ticket SSO e quindi cerca le credenziali dell'utente per l'applicazione (passaggio 3). Il server SSO B restituisce le credenziali all'adapter di trasmissione (passaggio 4) che le utilizza per inviare un messaggio con l'autenticazione appropriata all'applicazione affiliata (passaggio 5).

Amministrazione di SSO

Enterprise Single Sign-on include inoltre strumenti di amministrazione che consentono di eseguire diverse operazioni. Tutte le operazioni eseguite nel database SSO vengono controllate, pertanto sono disponibili strumenti che consentono a un amministratore di monitorare queste operazioni e di impostare vari livelli di controllo. Altri strumenti consentono a un amministratore di disabilitare una determinata applicazione affiliata, attivare e disattivare un singolo mapping per un utente ed eseguire altre funzioni. È inoltre disponibile una utilità client che consente agli utenti finali di configurare mapping e credenziali personalizzati. Analogamente ad altri componenti di BizTalk Server, Enterprise Single Sign-On espone i propri servizi tramite un'API programmabile. Gli autori di adapter BizTalk Server di terze parti utilizzano questa API per accedere ai servizi SSO, mentre gli amministratori possono utilizzarla per creare script per l'automazione di attività comuni.

Nell'esempio descritto in precedenza viene illustrato un utilizzo tipico di Enterprise Single Sign-On, ma questo servizio può essere configurato in altri modi. Un'installazione di BizTalk Server di dimensioni minori potrebbe includere un unico server SSO, ad esempio, ed è possibile utilizzare Enterprise Single Sign-On in modo indipendente dal motore BizTalk Server. Questa tecnologia viene inoltre fornita con Microsoft Host Integration Server.

Vedere anche

Motore di messaggistica di BizTalk Server
Implementazione di Enterprise Single Sign-On