Il presente articolo è stato tradotto automaticamente.

AD FS 2.0 nelle soluzioni basate sulle identità

Utilizzo di Active Directory Federation Services (ADSF) 2.0 in soluzioni basate sulle identità

Zulfiqar Ahmed

Scaricare il codice di esempio

Come sviluppatore, probabilmente si saprà qualcosa su Windows identità Foundation (WIF) denominato in precedenza “ Geneva Framework ”, che fornisce un'API potente per le applicazioni di abilitare le attestazioni e di creare servizi token di protezione personalizzato. Forse meno familiare all'utente è Active Directory Federation Services versione 2.0 (AD FS 2.0), codice originariamente denominato “ Geneva server ” che è una singola procedura di soluzione (SSO) e la federazione di aziende. AD FS 2.0 è un'evoluzione di AD FS 1.0 e supporta (ws-trust) attivo e passivi scenari (WS-Federation e SAML 2.0).

In questo articolo, è possibile iniziare con una panoramica delle AD FS 2.0 e quindi consentono di comprendere come gli sviluppatori possono utilizzare AD FS 2.0 nelle loro soluzioni di identità. È attiva la funzionalità di rilascio token di AD FS 2.0, basato sulla versione Beta 2. Come si vede da di Figura 1, questo rilascio token è solo un piccolo segmento di AD FS 2.0, ma si tratta di uno di particolare interesse per gli sviluppatori .NET lo spostamento verso l'identità federata. Dal punto di vista dell'architettura, AD FS 2.0 si basa su WIF e Windows Communication Foundation (WCF), in tal caso se si ha familiarità con queste tecnologie, è possibile destro a casa con AD FS 2.0.

Figura 1 di architettura di Active Directory Fi 2.0

Cenni preliminari su AD FS 2.0

Ad alto livello AD FS 2.0 è un insieme di servizi illustrato in di Figura 2.

Alla base di AD FS 2.0 è un servizio token di protezione (STS) che utilizza Active Directory come archivio di identità e LDAP (Lightweight Directory Access Protocol), SQL o un archivio personalizzato come un archivio di attributo. STS nel AD FS 2.0 per emettere i token di protezione per il chiamante utilizzando protocolli diversi, tra cui ws-trust, WS-Federation e SAML (Security Assertion Markup Language) 2.0. Il servizio STS Fi 2.0 Active Directory supporta inoltre i formati dei token SAML 1.1 e 2.0 di SAML.

AD FS 2.0 è progettato con una netta separazione tra i protocolli di rete e il meccanismo di rilascio token interno. Protocolli wire diversi vengono trasformati in un modello di oggetti standardizzati all'ingresso del sistema mentre internamente AD FS 2.0 utilizza lo stesso modello di oggetto per ogni protocollo. Questa separazione consente AD FS 2.0 offrire un modello di estendibilità pulito, indipendentemente dalla complessità dei protocolli wire diverso. Ulteriori dettagli di Active Directory 2.0 Fi estendibilità verrà fornito in Active Directory Fi 2.0 SDK precedenti alla RTM.

Nella figura 2 componenti di AD FS 2.0

AD FS 2.0 come un provider di identità

È possibile utilizzare AD FS 2.0 in diversi scenari comuni. Lo scenario più semplice e più comune è utilizzare AD FS 2.0 come provider di identità in modo che per emettere i token SAML per le identità che consente di gestire. A tal fine, è necessario creare un nuovo componente. Un componente in AD FS 2.0 è una rappresentazione di un'applicazione (un sito Web o un servizio Web) e contiene tutte le relative alla sicurezza informazioni, quali il certificato di crittografia, dichiara le regole di trasformazione e così via.

Impostazione di un componente

L'impostazione di un nuovo componente tramite AD FS 2.0 è semplice. È possibile accedere a installazione guidata festa affidandosi tramite il nodo Criteri di Active Directory Fi 2.0 Management console. Una volta, l'utente o l'amministratore di sistema deve specificare le origini dati appropriate nella pagina Seleziona origine dati della procedura guidata, illustrata in di Figura 3.

Nella figura 3 Seleziona pagina di origine dati di installazione guidata di componente di applicazione part

Le prime due opzioni consentono di configurare automaticamente il componente utilizzando i metadati di federazione. Se si dispone dell'accesso ai metadati di federazione del componente in una rete o in un file locale, selezionare una di queste due opzioni perché sono meno soggette a errori, essi automatizzare l'intero processo e aggiornamento automatico se tutti i dettagli di componente modificati in futuro. Queste opzioni sono un miglioramento importante rispetto AD FS 1.0, non offre tali processi automatizzati.

La terza opzione richiede di immettere manualmente tutti i dettagli di configurazione. Utilizzare questa opzione solo quando non si dispone dell'accesso ai metadati di federazione o si desidera controllare i dettagli della configurazione componente di applicazione di terze parti.

È istruttivo per l'esecuzione tramite l'opzione “ immettere manualmente configurazione componente di applicazione di terze parti ” in modo è possibile visualizzare tutte le fasi necessarie per impostare un nuovo componente. Nelle pagine successive della procedura guidata, verrà chiesto di scegliere un profilo, scegliere Active Directory Fi 2.0 profilo se si desidera supportare i client basati su browser sia basata su WCF o 1.x AD FS profilo se solo necessario AD FS 1.x interoperabilità e non supportano i client attivi (WCF, CardSpace); configurare il certificato utilizzato per crittografare il token in modo che solo il componente con la chiave privata corrispondente è in grado di decrittografare e utilizzare il token rilasciato; e configurare l'identificatore che verrà utilizzato per identificare questo componente in tutte le richieste di rilascio token.

Una volta terminata l'aggiunta guidata festa affidandosi, verrà aperto uno strumento Editor regole. In questo strumento, è possibile configurare le regole di rilascio e la trasformazione di attestazioni. Nella figura 4 viene illustrato lo strumento Editor regole configurato per emettere un token con una singola attestazione cui valore verrà recuperato dall'archivio principale attributo. Si noti che l'attributo displayName viene mappato per l'attestazione nome specificato. AD FS 2.0 introduce un nuovo linguaggio specifici del dominio testuale che consente di definire semplici regole per la derivazione del processo di rilascio e la trasformazione di attestazioni. Ogni regola è costituita da una condizione e un'azione e le estremità, ovvero come in [c] = > un; ovvero con un punto e virgola. La logica di trasformazione è una serie di regole in modo sequenziale eseguire durante il processo di rilascio token. In di Figura 4, la scheda visualizzazione Simple fornisce un'interfaccia utente per definire queste regole. La scheda visualizzazione avanzata consente di autore regole direttamente mediante il linguaggio specifico del dominio.

Nella figura 4 Tool Editor regole

In questo esempio è stato illustrato quanto sia semplice configurare una parte del componente di applicazione attendibile in AD FS 2.0. A questo punto, quando AD FS 2.0 riceve una richiesta di emissione token, estrae un identificatore dal protocollo di comunicazione (ad esempio, l'elemento appliesTo in caso di ws-trust) e viene utilizzato per la ricerca di un componente di destinazione. Una volta che un componente viene trovato, le impostazioni specificate nella procedura guidata vengono utilizzate per derivare la logica di rilascio token.

Ora let’s esaminare come utilizzare WCF per richiedere un token per questo componente da AD FS 2.0.

Che richiede un token con WCF

Esistono due opzioni per l'interazione con Active Directory 2.0 Fi STS l'uso di WCF:

• Acquisire in modo esplicito un token che agisce come un client ws-trust
• Configurare un client WCF in modo che l'infrastruttura in modo implicito acquisisce un token come parte della chiamata

Nell'opzione esplicita, la classe WSTrustClient fornisce un'API semplice e diretta ai token richiesta da un STS utilizzando il protocollo WS-Trust, come illustrato di seguito.

string baseUri = "https://bccoss.com/";

WindowsWSTrustBinding binding = new WindowsWSTrustBinding(SecurityMode.Transport);

WSTrustClient tokenClient = new WSTrustClient(binding,
    new EndpointAddress(baseUri + "Trust/2005/WindowsTransport/"),
    TrustVersion.WSTrustFeb2005,
    new ClientCredentials());

//create a token issuance issuance
RequestSecurityToken rst =
    new RequestSecurityToken(WSTrustFeb2005Constants.RequestTypes.Issue);
//Relying Party’s identifier
rst.AppliesTo = new EndpointAddress("http://local.zamd.net/");
//call ADFS STS
SecurityToken token = tokenClient.Issue(rst);

Questo codice richiede un token utilizzando l'autenticazione di Windows con protezione del trasporto. Come si può vedere, in modalità esplicita, è possibile accedere al token non elaborati, è possibile utilizzare per chiamare servizi in un secondo momento. Ad esempio, in un'applicazione smart client, si potrebbe acquisire token per diversi servizi in fase di avvio o l'account di accesso dell'applicazione, salvarli in una cache token e quindi utilizzarli tutta la durata dell'applicazione di chiamare servizi back-end diversi. Inoltre, in uno scenario in cui molti servizi di live nel limite di protezione logica stessa, condividere lo stesso certificato è possibile utilizzare la modalità explicit per acquisire un token singolo e quindi utilizzarlo quando si chiamano i servizi.

 In un ambiente di prova in cui in genere hanno accesso alla chiave privata del componente, è possibile utilizzare il codice riportato di seguito per estrarre un'asserzione SAML dal token restituito.

//Private Key certificate of RP (local.zamd.net)
X509Certificate2 rpCertificate = new X509Certificate2("zamd.net.pfx", "pwd");
string assertion = Util.ExtractSAMLAssertion(token, rpCertificate);

<saml:Attribute AttributeName="givenname" AttributeNamespace="https://schemas.xmlsoap.org/ws/2005/05/identity/claims">
    <saml:AttributeValue>Zulfiqar Ahmed</saml:AttributeValue>
</saml:Attribute>

Il token SAML contiene solo le attestazioni configurate per questo particolare componente. Fare riferimento Figura 4 , che mostra come token di output di questo componente è stato configurato per restituire un singolo attributo. È possibile modificare la configurazione del componente per includere ulteriori attestazioni nell'output e dovrebbe essere visualizzato tutte riportate di seguito. È possibile utilizzare anche le attestazioni criterio lingua direttamente per definire la trasformazione RTF e logica di filtro.

L'API di WSTrustClient e nuove associazioni di WSTrust fanno parte di WIF, in modo che per il funzionamento del codice precedente, WIF deve essere installato sul client. È inoltre possibile utilizzare l'API di WCF direttamente per acquisire in modo esplicito un token, ma la semplicità e facilità di utilizzo WIF offerte può richiedere un'attività di disattivare l'elenco di cose da fare.

Nel codice in di Figura 5, IssuedSecurityTokenProvider è l'equivalente WCF di WSTrustClient e in genere viene utilizzata da wsFederationBinding quando vengono richiesti i token per conto dell'utente. Poiché si tratta di un'API pubblica, si è liberi di utilizzare nel codice è necessario accedere a un token non elaborato. È equivalente a WindowsWSTrustBinding di CustomBinding.

Nella figura 5 utilizzo IssuedSecurityTokenProvider di accedere a un token RAW

sstring baseUri = "https://bccoss.com/";

//Limited edition of WSTrustClient:)
IssuedSecurityTokenProvider provider = new IssuedSecurityTokenProvider();
provider.SecurityTokenSerializer = new WSSecurityTokenSerializer();

//Relying Party's identifier
provider.TargetAddress = new EndpointAddress(new Uri("http://local.zamd.net"));
provider.IssuerAddress = new EndpointAddress(new Uri(baseUri + "Trust/2005/WindowsTransport/"));

provider.SecurityAlgorithmSuite = SecurityAlgorithmSuite.Basic256;
provider.MessageSecurityVersion = MessageSecurityVersion.
WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;

HttpsTransportBindingElement tbe = new HttpsTransportBindingElement();
tbe.AuthenticationScheme = AuthenticationSchemes.Negotiate;
CustomBinding stsBinding = new CustomBinding(tbe);

provider.IssuerBinding = stsBinding;
provider.Open();
//Request a token from ADFS STS
SecurityToken issuedToken = provider.GetToken(TimeSpan.FromSeconds(30));

Nell'opzione implicita, è possibile utilizzare wsFederationHttpBinding standard, in cui caso l'infrastruttura WCF in modo trasparente acquisisce il token e lo invia al servizio come parte della chiamata. Ogni volta che si crea un nuovo proxy WCF e utilizzarlo per chiamare un servizio, l'infrastruttura recupera un nuovo token per l'utente. Ovviamente, questo sarebbe eccessivo in alcuni scenari. Il codice in di Figura 6 consente di configurare un EmployeeService fittizio per richiedere i token dalla AD FS 2.0.

Nella figura 6 Using wsFederationHttpBindingto Acquisisci in modo un token implicito

<system.serviceModel>
  <services>
    <service name="EmployeeService.EmployeeService">
      <endpoint address="http://localhost:9990/ES"
        binding="ws2007FederationHttpBinding"
        contract="EmployeeServiceContract.IEmployeeService"
        bindingConfiguration="adfsFed"/>
    </service>
  </services>
  <bindings>
    <ws2007FederationHttpBinding>
      <binding name="adfsFed">
        <security mode="Message">
          <message negotiateServiceCredential="false" >
            <issuer address="https://bccoss.com/Trust13/KerberosMixed"
               binding="customBinding" bindingConfiguration="MixedKerberos"/>
          </message>
        </security>
      </binding>
     </ws2007FederationHttpBinding>
     <customBinding>
       <binding name="MixedKerberos">
         <security authenticationMode="KerberosOverTransport"/>
         <httpsTransport/>
       </binding>
     </customBinding>
   </bindings>
</system.serviceModel>

Mapping AD FS 2.0 concetti di WCF

Responsabilità fondamentale di AD FS 2.0 è di rilasciare token agli utenti autenticati. Gli utenti possono essere autenticati utilizzando meccanismi di autenticazione (ad esempio, l'autenticazione di Windows). È possibile visualizzare tutti i meccanismi di autenticazione supportati, selezionare il nodo dell'endpoint nella console di gestione.

Si noterà che due concetti di protezione WCF familiari come intestazioni di colonna all'interno del nodo dell'endpoint:

• Il tipo di autenticazione è AD FS 2.0 equivalente della terminologia clientCredentialType WCF.
• Le opzioni modalità di protezione sono trasporto, messaggi o Mixed. Misto equivale AD FS 2.0 di TransportWithMessageCredentials di WCF.

Diverse combinazioni di questi due valori sono esposte mediante endpoint differenti e si sceglie un endpoint specifico in base alle esigenze di autenticazione. Ad esempio, se è necessario eseguire l'autenticazione tramite il nome utente/password, scegliere l'endpoint di tipo di autenticazione Cancella Password.

Per Active Directory 2.0 Fi STS, mapping questi concetti indirizzo, associazione e contratto (ABC) in WCF, è possibile ottenere gli equivalenti seguenti:

• Indirizzo = Active Directory 2.0 Fi indirizzo di base + percorso URL dell'endpoint
• Associazione = modalità di protezione + tipo di autenticazione dell'endpoint
• Contratto = standard WS-Trust protocollo

La federazione a AD FS 2.0 con un altro servizio STS

Oltre a creare le parti componente di applicazione, è possibile stabilire una relazione di trust tra AD FS 2.0 e il servizio STS personalizzato o un altro AD FS 2.0. Ad esempio, se si dispone già di un servizio STS che autentica gli utenti ed emette i token, è possibile semplicemente aggiungerlo come un provider di identità attendibili all'interno AD FS 2.0, cui accetterà i token rilasciati dal servizio STS.

Impostazione di un provider di identità

Impostazione di un provider di identità attendibili, di nuovo AD FS 2.0 è simile all'impostazione di un nuovo componente. La procedura guidata Aggiungi Provider di identità è utilizzare aspetto e funzionamento molto simile all'aggiunta guidata entità che si basano (fare riferimento a di Figura 3).

Per ottenere la pagina Configura Identifier, selezionare l'opzione di configurazione manuale nuovamente (come accadeva nel di Figura 3) e selezionare AD FS 2.0 profilo nella pagina Selezione profilo. Lasciare le impostazioni predefinite nella pagina Configura URL. Quindi scegliere un identificatore e un certificato a chiave pubblica per il provider di identità e completare la procedura guidata per registrare il nuovo provider di identità.

Che richiede un token con WCF

Una volta che si registra un provider di identità aggiuntivi con AD FS 2.0, l'architettura logica è simile a configurazione illustrata in di Figura 7.

Nella figura 7 Architecture of AD FS 2.0 con un provider di identità aggiuntivi

Il codice in di Figura 8 consente di acquisire un token in modo esplicito, garantendo la flessibilità per memorizzare nella cache il token localmente e inviare al servizio, se necessario.

Nella figura 8 utilizzo IssuedTokenWSTrustBinding per acquisizione esplicita di un token

string adfsStsUri = "http://bccoss.com/Trust/2005/IssuedTokenAsymmetricBasic256";

//binding for local STS(IP-STS)
WSHttpBinding localStsBinding = new WSHttpBinding(SecurityMode.Message);

localStsBinding.Security.Message.ClientCredentialType = MessageCredentialType.None;
localStsBinding.Security.Message.EstablishSecurityContext = false;
localStsBinding.Security.Message.NegotiateServiceCredential = false;

EndpointAddress localStsEpr = new EndpointAddress(
   new Uri("http://localhost:9000/STS/"),
   new X509CertificateEndpointIdentity(new X509Certificate2(@"MyCustomSTSPublicKey.cer")));

//This binding will transparently acquire all the intermediate tokens as part of the call. (R-STS)
IssuedTokenWSTrustBinding fedBinding = new IssuedTokenWSTrustBinding(localStsBinding, localStsEpr);
fedBinding.TrustVersion = TrustVersion.WSTrustFeb2005;

EndpointAddress adfsStsEpr = new EndpointAddress(
    new Uri(adfsStsUri),
    new X509CertificateEndpointIdentity(new X509Certificate2("AdfsStsPubicKeyOnly.cer")));

WSTrustClient trustClient = new WSTrustClient(fedBinding, adfsStsEpr, TrustVersion.WSTrustFeb2005,
null);

//Create a security token request
RequestSecurityToken rst = new RequestSecurityToken(RequestTypeConstants.Issue);
//Set Relying Party's identifier accordingly
rst.AppliesTo = new EndpointAddress("http://local.zamd.net");

SecurityToken finalToken = trustClient.Issue(rst);

In quanto consente di nascondere tutte le complessità di token intermedie tramite telefono in modo trasparente con il servizio STS IP per acquisire un token intermedio che viene quindi inviato al servizio STS R come token di autenticazione, è molto simile a wsFederationHttpBinding IssuedTokenWSTrustBinding.

Il codice in di Figura 9 utilizza wsFederationHttpBinding per abilitare un client WCF acquisire in modo implicito un token come parte di una chiamata al servizio.

Si noti che si sta utilizzando un customBinding quando comunica con l'endpoint /IssuedTokenMixedSymmetricBasic256. WsFederationHttpBinding standard non funziona qui perché cerca di stabilire una sessione protetta, che è incompatibile con questa AD FS 2.0 endpoint. Per attuare la federazione client WCF con AD FS 2.0, è necessario utilizzare un customBinding o uno dei nuovi basato su trust WS binding fornito con WIF.

Nella figura 9 wsFederationHttpBinding using per acquisire in modo un token implicito

<system.serivceModel>
   <bindings>
      <wsFederationHttpBinding>
         <binding name="R-STS">
            <security mode="Message">
               <message>
                  <issuer address="https://bccoss.com/Trust/2005/IssuedTokenMixedSymmetricBasic256" binding="customBinding" bindingConfiguration="IP-STS"/>
               </message>
            </security>
         </binding>
      </wsFederationHttpBinding>

      <customBinding>
         <binding name="IP-STS">
            <security authenticationMode="IssuedTokenOverTransport">
               <issuedTokenParameters>
                  <issuer address="http://localhost:9000/CustomSTS" binding="wsHttpBinding"/>
               </issuedTokenParameters>
            </security>
            <httpsTransport/>
         </binding>
      </customBinding>
   </bindings>

   <client>
      <endpoint address="http://localhost:9990/ES" binding="wsFederationHttpBinding" bindingConfiguration="R-STS"
contract="ServiceReference1.IEmployeeService" name="WSFederationHttpBinding_IEmployeeService"/>
      </client>
</system.serviceModel>

AD FS 2.0 e dei client browser

AD FS 2.0 dispone del supporto di prim'ordine per Web single Sign-On (WebSSO) e la federazione utilizzando protocolli WS-Federation e 2.0 di SAML.

WS-Federation e il protocollo SAML dal punto di vista concettuale, sono simili anche se hanno rappresentazioni cavo diverso. Il formato di trasmissione WS-Federation è strettamente correlato al protocollo WS-Trust, in modo che sia la scelta logica quando si stanno che gestiscono i client attivi e passivi (basate sul browser). Il protocollo SAML presenta una migliore interoperabilità tra diversi fornitori. AD FS 2.0 supporta nativamente entrambi questi protocolli. È buona norma utilizzare un singolo protocollo (ad esempio, WS-Federation) all'interno del limite di protezione e l'utilizzo AD FS 2.0 come un hub di Service broker di protocollo per SSOs in ingresso o in uscita.

Let’s si consideri un esempio. Si supponga di disporre di una semplice applicazione ASP.NET che fornisce funzionalità solo per gli utenti autenticati. Come applicazione autonoma, logica di autenticazione viene implementata come parte dell'applicazione e un'interazione con questa applicazione verrebbe seguire i passaggi illustrati in di Figura 10.

Nella figura 10 Direct Authentication in un'applicazione ASP.NET semplice

Di seguito vengono implementati i meccanismi di autenticazione ASP.NET abituali, ad esempio l'autenticazione basata su form. Il nostro obiettivo consiste nell'estrarre la funzionalità di autenticazione da questa applicazione e utilizzare invece AD FS 2.0.

In Active Directory l'installazione Fi 2.0, che è illustrata nella di Figura 11, l'applicazione diventa una parte del componente di applicazione attendibile all'interno AD FS 2.0 e pertanto considerato trusted dal token rilasciato da Active Directory 2.0 FS. L'applicazione utilizza WIF per eseguire tutte le lifting pesante del token l'analisi, l'estrazione dei reclami e così via. Vengono fornite informazioni di identità per l'applicazione utilizzando le astrazioni di IPrincipal/IIdentity standard.

Autenticazione distribuita in AD FS 2.0 è molto più flessibile rispetto all'autenticazione diretto e fornisce alcuni dei vantaggi principali:

• L'autenticazione è externalized dall'applicazione, in modo che il meccanismo di autenticazione può essere modificato senza alterare l'applicazione (ad esempio, da nome utente per Kerberos).
• La flessibilità di un modello di attestazioni può fornire le informazioni necessarie per l'applicazione (come parte del token) direttamente anziché l'applicazione stessa il recupero di tali informazioni da origini diverse.

La versione Beta 2 di WIF introdotti nuovi modelli di progetto che semplificano la logica di autenticazione di un'applicazione a un servizio STS di externalize. Redazione di questo, questi modelli sono disponibili solo in C#.

Nella figura 11 Distributed Authentication in AD FS 2.0

Logica di autenticazione externalizing

Per externalize logica di autenticazione di un'applicazione, è possibile utilizzare la finestra di dialogo Nuovo sito Web Microsoft Visual Studio. Selezionare il modello di Claims-aware Web Site per creare un sito di ASP.NET Web standard che è preconfigurato con WIF.

Per avviare la procedura guidata utilità di federazione, illustrata nella di Figura 12, fare clic con il pulsante destro del mouse sul nodo sito Web in Esplora soluzioni e scegliere Modifica STS riferimento dal menu.

Nella figura 12 federazione utilità

In questo esempio, è opportuno scegliere l'opzione “ utilizza un STS esistente ” e specificare AD FS 2.0 come il servizio STS. La procedura guidata richiede l'URL del documento dei metadati automatizzare le configurazioni necessarie. L'URL del documento di metadati è disponibile come un endpoint all'interno AD FS 2.0.

La federazione metadati contengono informazioni essenziali, ad esempio STS la firma del certificato, le attestazioni offerte e l'URL di rilascio token. Presenza di un formato standardizzato per queste informazioni consentono gli strumenti automatizzare la creazione di relazioni di trust tra un STS e che si basano le parti.

La pagina Riepilogo della procedura guidata vengono riepilogate le modifiche che verranno apportate nel file web.config.

La procedura guidata federazione utilità Configura WIF sul sito Web per fornire la seguente funzionalità:

• Tutte le richieste non autenticate verranno reindirizzate per AD FS 2.0.
• Le richieste contenenti un token valido verranno elaborata e verranno presentate le informazioni di identità all'applicazione sotto forma di ClaimsIdentity/ClaimsPrincipal. L'applicazione continuerà accedere alle informazioni di identità utilizzando le astrazioni standard di IPrincipal/IIdentity indipendentemente dall'origine di tali informazioni.

Prima di testare l'applicazione, è necessario apportare un'ultima configurazione modificare su AD FS 2.0. È necessario aggiungere un endpoint aggiuntivo al componente per i client browser. Questo endpoint è necessario perché una volta AD FS 2.0 ha elaborato una richiesta di emissione token, due tipi di informazioni sono necessarie prima di poter inviare il token al browser:

• L'indirizzo in cui è necessario inviare il token
• Il protocollo (SAML o WS-Federation) su cui è necessario inviare il token

È possibile aggiungere un endpoint di tipo passivo per il componente nella scheda endpoint della finestra di dialogo Proprietà-RP di prova. Ad esempio, se si seleziona il tipo di endpoint WS-Federation, AD FS 2.0 invierà i token al componente tramite il protocollo WS-Federation. All'interno di componente, WIF, che comprenda in modo nativo protocollo WS-Federation elabora questi token.

Ora quando si tenta di individuare l'applicazione, si viene reindirizzati automaticamente AD FS 2.0 per l'autenticazione, in cui è possibile scegliere il metodo di autenticazione che si desidera utilizzare: L'autenticazione integrata di Windows, autenticazione certificati o form di nome utente/password.

Una volta l'autenticazione ha esito positivo, si, ovvero con un token rilasciato da AD FS 2.0, ovvero reindirizzato all'applicazione. WIF elabora questo token e rende disponibili all'applicazione utilizzando i meccanismi standard di ASP.NET (ad esempio Page.User) identità finale (in formato di attestazioni).

Federazione basata su browser

È possibile estendere uno scenario esterno l'autenticazione di base in uno scenario di federazione mediante l'aggiunta di un provider di identità attendibili aggiuntive. Durante il processo di autenticazione vengono visualizzate le opzioni del provider di identità.

È possibile autenticare con AD FS 2.0 o un altro attendibili provider di identità. Se si seleziona un provider di identità differenti, è reindirizzato a tale provider di identità e, al momento l'autenticazione ha avuto esito positivo, reindirizzare nuovamente AD FS 2.0, che verrebbe quindi autenticare in base al token emesso dal provider di identità attendibili.

Combinazione potente

Come si è visto in questo articolo, Active Directory 2.0 Fi STS fornisce un semplicemente e soluzione già pronti per abilitare le attestazioni servizi WCF e le applicazioni basate su browser. STS stesso è solo un piccolo segmento di AD FS 2.0, che comprende anche un CardSpace provisioning system, un motore di trasformazione di attestazioni basate sulle regole, servizi dell'infrastruttura, gestione e configurazione di gestione trust automatico e i propri strumenti rispettivi. WIF, con AD FS 2.0 crea una combinazione potente per soluzioni programma identità sulla piattaforma Windows.

Zulfiqar Ahmed è un consulente senior del team UK Application Development Consulting (ADC) ed è possibile contattarlo all'indirizzo http://zamd.net .