Il presente articolo è stato tradotto automaticamente.

Identità federative

Autenticazione passiva per ASP.NET con WIF

Michele Leroux Leroux

L'obiettivo di protezione federata è fornire un meccanismo per stabilire relazioni di trust tra domini, in modo che gli utenti possono eseguire l'autenticazione per il proprio dominio mentre è concesso l'accesso alle applicazioni e servizi che appartengono a un altro dominio. Ciò rende possibili le tecniche di autenticazione come single Sign-on, Elimina la necessità di provisioning e gestire account per utenti duplicati tra le applicazioni e i domini e riduce significativamente i costi per estendere le applicazioni per parti attendibili.

In un modello di protezione federata, un provider di identità (IdP) esegue l'autenticazione e fornisce un servizio token di protezione (STS) per i token di protezione del problema. Questi token asserzione a sua volta le informazioni relative all'utente autenticato: sua identità ed eventualmente altre informazioni quali ruoli e diritti di accesso più granulari. In un ambiente federato, queste informazioni viene definite come attestazioni e controllo di accesso basato su attestazioni è fondamentale per un modello di protezione federata. In questo modello, applicazioni e servizi di autorizzano l'accesso alle caratteristiche e funzionalità in base alle attestazioni di autorità emittenti attendibili (STS).

Gli strumenti per la piattaforma come Windows Identity Foundation (WIF) semplificano molto questo tipo di federazione di identità. WIF è una struttura di modello di identità per la creazione di servizi e applicazioni basati sulle attestazioni e di supporto basato su SOAP (attivo) e scenari basati su browser federazione (passivo). Nell'articolo “ autorizzazione basata su attestazioni con WIF , ” nel numero di novembre 2009 di MSDN Magazine, mi sono concentrato sull'utilizzo WIF con Windows Communication Foundation (WCF). In questo articolo descritto come implementare modelli di protezione basati sulle attestazioni per i servizi WCF e come eseguire la migrazione alla federazione di identità.

In questo articolo follow-up mi concentrerò sul federazione passiva. Verranno illustrare il flusso della comunicazione per federazione passiva, mostra diverse tecniche per l'abilitazione della federazione nelle applicazioni ASP.NET, illustrare le tecniche di autorizzazione basati sulle attestazioni per ASP.NET e parlare di scenari usciti Sign-on e unico singoli. Lungo il percorso, spiegherò i componenti che supportano scenari di federazione passivo e funzionalità WIF sottostanti.

Nozioni fondamentali di federazione passivo

Federazione passivo scenari sono basati sulla specifica WS-Federation. Descrive come richiedere i token di protezione e come pubblicare e acquisire documenti dei metadati di federazione, che rende semplice stabilire relazioni di trust. WS-Federation descrive inoltre le procedure single Sign-on e uscite e altri concetti di implementazione di federazione.

Mentre WS-Federation vengono illustrati molti dettagli sulla federazione, sono presenti sezioni dedicate alla federazione basata sul browser che si basano su HTTP GET e POST, reindirizzamenti del browser e dei cookie per raggiungere l'obiettivo.

Alcuni aspetti della messaggistica federazione passiva sono strettamente basati sulla specifica WS-trust. Ad esempio, federazione passiva impiega un modulo compatibile con browser di RST (Request Security Token) e risposta RST (RSTR) quando viene richiesto un token di protezione di un servizio STS. Nello scenario della federazione passivo, verrà chiamo la RST un messaggio di richiesta di accesso e il messaggio di risposta RSTR un segno in. La specifica WS-trust è incentrato sulla federazione (attiva) basato su SOAP, ad esempio tra i client Windows e i servizi WCF.

Di Figura 1 è illustrato uno scenario semplice federazione passivo.

Figura 1 di semplice scenario federazione passivo A

Agli utenti l'autenticazione al dominio e vengono concesso l'accesso a un'applicazione Web in base ai relativi ruoli. I partecipanti a questo schema di autenticazione includono l'utente (soggetto), un browser Web (richiedente), un'applicazione ASP.NET, il componente o RP, IdP responsabile dell'autenticazione degli utenti all'interno del dominio e un STS appartenente al dominio dell'utente (STS IP). Una sequenza di reindirizzamenti browser garantisce che l'utente viene autenticato al suo dominio prima di accedere la RP.

L'utente accede all'applicazione RP (1), viene reindirizzato alla sua IdP sia autenticato (2). Se l'utente non è ancora stato autenticato con il IdP, IP-STS può presentare una sfida o Lei il reindirizzamento a una pagina di accesso per raccogliere le credenziali (3). L'utente fornisce il suo credenziali (4) e viene autenticato dal servizio STS IP (5). A questo punto, IP-STS emette un token di protezione in base alla richiesta di accesso e la risposta di accesso contenente il token viene registrata RP tramite browser reindirizzamento (6). Il RP elabora il token di protezione e autorizza l'accesso basato su attestazioni che viene eseguita (7). Se autorizzato correttamente, viene visualizzata la pagina che ha originariamente richiesta e restituito un cookie di sessione (8).

L'implementazione di questo scenario passivo federazione con WIF e ASP.NET richiede solo pochi passaggi:

1. Stabilire una relazione di trust tra RP e IdP (IP STS)
2. Abilitare la federazione passiva per l'applicazione ASP.NET
3. Implementare controlli di autorizzazione per controllare l'accesso alle funzionalità dell'applicazione nelle sezioni successiva che illustrerò le funzionalità di WIF che supportano federazione passiva, esaminare le procedure per configurare questo scenario semplice e quindi esplorare altre considerazioni pratiche per questo e per altri scenari.

Caratteristiche WIF per federazione passiva

Prima di parlare di implementazione, Consenti la verifica delle funzionalità di WIF utile soprattutto per la federazione delle identità nelle applicazioni ASP.NET. Per cominciare, WIF fornisce i seguenti moduli HTTP utili:

• WSFederationAuthenticationModule (FAM): Abilita federazione basata su browser, gestione reindirizzamento a STS appropriato per l'autenticazione e l'emissione del token e l'elaborazione della risposta risultante Accedi a hydrate il token di protezione emesso in un ClaimsPrincipal da utilizzare per l'autorizzazione. Questo modulo gestisce anche altri messaggi di federazione importanti quali richieste in uscita.
• SessionAuthenticationModule (SAM): Gestisce la sessione autenticata generando il token di protezione sessione contiene il ClaimsPrincipal, la scrittura di un cookie, gestire la durata del cookie di sessione e rehydrating ClaimsPrincipal dal cookie quando viene presentata. In questo modulo viene inoltre mantenuta una cache del token di sessione locale.
• ClaimsAuthorizatonModule: Fornisce un punto di estendibilità per installare un ClaimsAuthorizationManager personalizzato può essere utile per i controlli di accesso centralizzato.
• ClaimsPrincipalHttpModule: Crea un ClaimsPrincipal dall'identità dell'utente corrente associato al thread di richiesta. Fornisce inoltre un punto di estendibilità per installare un ClaimsAuthenticationManager personalizzato può essere utile per la personalizzazione ClaimsPrincipal da collegare ai thread di richiesta.

ClaimsPrincipalHttpModule risulta particolarmente utile per le applicazioni senza la federazione passiva. È possibile pensare è uno strumento utile per l'implementazione di un modello di protezione basato su attestazioni nell'applicazione ASP.NET prima di passare alla federazione passiva. Ho parlato di questa tecnica per WCF nel mio articolo precedente.

Tre moduli in genere vengono utilizzati insieme per federazione passiva, sebbene ClaimsAuthorizationModule è facoltativo. Figura 2 illustra come questi moduli principali rientrano in pipeline di elaborazione della richiesta e le funzioni in una richiesta di autenticazione federata tipica.

Figura 2 WIF componenti e moduli partecipando passiva di Federation

Tenendo presente il flusso di federazione passivo da di Figura 1, quando l'utente accede prima a una pagina protetta RP (1), è verrà negato l'accesso all'applicazione. Il FAM elabora le richieste non autorizzate, genera il messaggio di accesso e l'utente viene reindirizzato al servizio STS IP (2). IP-STS autentica l'utente (3), produce una risposta di accesso contenente il token di protezione emesso e reindirizza nuovamente l'applicazione RP (4).

Il FAM elabora la risposta di segno, garantendo che la risposta contiene un token di protezione validi per l'utente autenticato e hydrates un ClaimsPrincipal dal segno-in risposta (5). Questo imposterà l'identità di protezione per il thread di richiesta e HttpContext. Il FAM utilizza quindi il SAM per serializzare le attestazioni ­ Principal a un cookie HTTP (6) durante la sessione del browser verrà presentato le richieste successive. Se è installato ClaimsAuthorizationModule, richiamerà il configurato ClaimsAuthorization ­ gestione, fornendo la possibilità di eseguire l'accesso globale confrontato (7) ClaimsPrincipal prima di accedere alla risorsa richiesta.

Una volta che la risorsa richiesta è presentata, controllo di accesso è possibile implementare i controlli di accesso ASP.NET tradizionali, controlla IsInRole e altro codice personalizzato richiede l'utente dichiara (8).

Le richieste successive viene presentato il token di sessione con cookie scritto in precedenza da SAM (9). Questa volta il SAM è impegnato per convalidare il token di sessione e rehydrate le attestazioni ­ principale dal token (10). Il FAM non è impegnato a meno che la richiesta è una segno nella risposta, una richiesta di uscita o se l'accesso viene negato, che può verificarsi se il token di sessione non è presente o è scaduto.

Oltre a questi moduli sono disponibili due controlli sono inoltre utili per federazione passiva:

• Controllo FederatedPassiveSignIn: Può essere utilizzato anziché il FAM se l'applicazione consente di reindirizzare tutte le chiamate non autorizzate per una pagina di accesso che contiene questo controllo solo quando è necessaria l'autenticazione. Si presume che l'utente interagisce con il segno-nel processo, utile negli scenari di autenticazione step-up in cui all'utente viene richieste credenziali, eventualmente ulteriori credenziali di accesso originale, come richiesto dall'applicazione. Il controllo gestisce il reindirizzamento per il servizio STS, l'elaborazione della risposta Accedi inizializzazione ClaimsPrincipal dalla risposta e stabilire una sessione protetta, sfruttando la funzionalità esposta dal FAM e SAM.
• Controllo FederatedPassiveSignInStatus: Questo controllo consente all'utente di accedere in modo interattivo o segno fuori dall'applicazione RP, incluso il supporto per federati uscita.

Figura 3 illustra come il flusso della comunicazione cambia quando viene utilizzato il controllo FederatedPassiveSignIn. L'applicazione si basa sull'autenticazione basata su form per proteggere le risorse e il reindirizzamento alla pagina di accesso, il controllo (1). L'utente fa clic sul controllo FederatedPassiveSignIn o può essere reindirizzato automaticamente a esso, che genera un reindirizzamento a STS (2). La pagina di controllo riceve la risposta dal servizio STS, affidarsi al FAM e SAM per elaborare la risposta in segno (3), hydrate le attestazioni ­ Principal e scrivere cookie della sessione (4). Quando l'utente viene reindirizzato alla pagina originariamente richiesta (5), SAM è impegnato per convalidare il cookie di sessione e hydrate ClaimsPrincipal per la richiesta. A questo punto il ClaimsAuthorizationModule e tale pagina può eseguire i controlli di autorizzazione, come illustrato in di Figura 2.

Figura 3 di federazione passiva con il FederatedPassive ­-controllo accesso

Il SAM e FAM dipendono l'appropriata protezione ­ TokenHandler tipo elaborare token in ingresso. All'arrivo di una risposta di segno di FAM scorre SecurityTokenHandlerCollection cercando il gestore del token corretto per leggere il token XML. In uno scenario con federato sarà generalmente Saml11Security ­ TokenHandler o Saml2Security ­ TokenHandler, sebbene altri formati dei token possono essere utilizzati se si aggiungono i gestori di token personalizzati. Per il SAM SessionSecurity ­ TokenHandler viene utilizzato per elaborare il token di sessione associato il cookie della sessione.

Diverse impostazioni di configurazione del modello di identità sono importanti per il flusso di federazione passivo e vengono utilizzati per inizializzare il FAM e SAM e il controllo FederatedPassiveSignIn (anche se quest'ultimo espone inoltre proprietà configurabili nella finestra di progettazione di Visual Studio). A livello di codice, è possibile fornire un'istanza del servizio da ­ tipo configurazione dallo spazio dei nomi Microsoft.IdentityModel.Configuration oppure è possibile fornire dichiarativa di configurazione nella sezione <microsoft.identityModel>. Figura 4 riepiloga le impostazioni del modello di identità, molti dei quali verranno descritti nelle sezioni successive.

Figura 4 di riepilogo di Essential <microsoft.identityModel> elementi

Abilitazione della federazione passiva

WIF consente di configurare la federazione passiva per le applicazioni ASP.NET. Un STS dovrebbe fornire metadati federazione (come descritto nella specifica WS-Federation) e WIF fornisce una federazione utilità (FedUtil.exe), che utilizza i metadati di federazione per stabilire relazioni di trust tra un RP e un STS (tra altre funzionalità utili per entrambi gli scenari attivi e passivi federazione). È possibile richiamare FedUtil dalla riga di comando o da Visual Studio facendo doppio clic sul progetto RP e selezionando STS Aggiungi riferimento.

È necessario completare i seguenti passaggi semplici con la procedura guidata FedUtil:

• La prima pagina della procedura guidata consente di confermare il file di configurazione da modificare tramite la procedura guidata e l'URI dell'applicazione RP.
• Nella seconda pagina richiede il percorso al documento XML di metadati federazione per STS con cui il RP stabilisce trust.
• La terza pagina consente di fornire un certificato da utilizzare per la decrittografia del token.
• Pagina finale viene visualizzato un elenco di attestazioni offerto tramite il servizio STS, che è possibile utilizzare per pianificare le decisioni di controllo di accesso, ad esempio.

Al termine della procedura guidata, FedUtil modifica del progetto aggiungere un riferimento all'assembly Microsoft.IdentityModel. Modifica inoltre il file web.config per installare i moduli FAM e SAM e di fornire impostazioni di configurazione del modello di identità per tali moduli. L'applicazione ora supporta la federazione passiva e reindirizzerà le richieste non autorizzate per il servizio STS attendibile.

C'è un presupposto qui è conoscenza del RP il servizio STS, quindi rilascerà token per gli utenti autenticati l'accesso al RP e ovviamente che dispone della chiave pubblica di RP richiede STS utilizzare per crittografare i token. Si tratta di un modo semplice per ottenere applicazioni ASP.NET impostate inizialmente per la federazione. Naturalmente, è utile per comprendere come impostare tale da zero nel caso in cui le rettifiche sono necessarie e come vanno oltre le impostazioni di base abilitate dalla procedura guidata. Mi concentrerò sull'approccio “ daccapo ” da qui in.

Senza utilizzare FedUtil, è necessario aggiungere manualmente un riferimento all'assembly Microsoft.IdentityModel e configurare manualmente il FAM e moduli SAM con le impostazioni del modello di identità necessaria. I moduli HTTP vengono aggiunte due sezioni: System.Web per Internet Information Services (IIS) 6 e System.WebServer per IIS 7. Se che l'applicazione è ospitata in IIS 7, moduli WIF sono configurati come segue:

<modules>
  <!--other modules-->
  <add name="SessionAuthenticationModule" 
    type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
    preCondition="managedHandler" />
  <add name="WSFederationAuthenticationModule" 
    type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
    preCondition="managedHandler" />
</modules>

Per impostazione predefinita questa configurazione proteggere solo le risorse con estensioni mappate in modo esplicito da gestire con la pipeline ASP.NET (.aspx, asax e così via). Per proteggere risorse aggiuntive con autenticazione federata, è necessario mappare le estensioni per la pipeline ASP.NET in IIS oppure impostare runAllManagedModulesForAllRequests su true in moduli di impostazione (solo IIS 7) come segue:

<modules runAllManagedModulesForAllRequests="true">

Per FAM avviare, è necessario inoltre impostare la modalità di autenticazione di ASP.NET su Nessuno e negare l'accesso alle risorse dell'applicazione gli utenti anonimi:

<authentication mode="None" />

<authorization>
  <deny users="?" />
</authorization>

Entrambi i moduli si basano sulle impostazioni di configurazione del modello di identità descritte in di Figura 4, un tipico esempio di cui viene mostrato in Figura 5 . La maggior parte di queste impostazioni sono generata da FedUtil, ad eccezione di certificateValidation e alcune delle impostazioni all'interno di federatedAuthentication. Si consiglia in genere di utilizzare modalità di convalida del certificato PeerTrust, che significa che è aggiungere esplicitamente tutti attendibili i certificati, incluso quello dell'autorità di certificazione attendibili all'archivio TrustedPeople del computer locale.

Figura 5 di identità modello di configurazione per federazione passiva

<microsoft.identityModel>
  <service>
    <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <trustedIssuers>
        <add thumbprint="EF38A0A6D1274766093D3D78BFE4ECA77C62D5C3" 
          name="http://localhost:60768/STS/" />
      </trustedIssuers>
    </issuerNameRegistry>
    <certificateValidation certificateValidationMode="PeerTrust" 
      revocationMode="Online" trustedStoreLocation="LocalMachine"/>
    <audienceUris>
      <add value="http://localhost:50652/ClaimsAwareWebSite2/" />
    </audienceUris>
    <federatedAuthentication>
      <wsFederation passiveRedirectEnabled="true" 
        issuer="http://localhost:60768/STS/" 
        realm="http://localhost:50652/ClaimsAwareWebSite2/" 
        requireHttps="true" />
      <cookieHandler requireSsl="true" name="FedAuth"  
        hideFromScript="true" path="/ClaimsAwareWebSite2" />
    </federatedAuthentication>
    <serviceCertificate>
      <certificateReference x509FindType="FindByThumbprint" 
        findValue="8A90354199D284FEDCBCBF1BBA81BA82F80690F2" 
        storeLocation="LocalMachine" storeName="My" />
    </serviceCertificate>
  </service>
 </microsoft.identityModel>

È in genere dovrebbe richiedere HTTPS/SSL per la federazione passiva proteggere il token rilasciato portante da attacchi diretti e HTTPS/SSL è necessario per i cookie di sessione. Per impostazione predefinita, i cookie sono nascoste dallo script, ma è un'importante impostazione, motivo per cui è possibile chiamare in di Figura 5.

Come per il nome e il percorso del cookie, il nome predefinito FedAuth, il percorso della directory dell'applicazione. È possibile specificare un nome univoco per il cookie, in particolare se molte applicazioni RP nella soluzione condividono lo stesso dominio. Al contrario, è possibile specificare un percorso generico quando si desidera che i cookie per essere condiviso tra più applicazioni nello stesso dominio.

Verrà in genere utilizzare FedUtil per configurare le applicazioni ASP.NET per federazione passiva utilizzando il FAM e SAM, quindi modificare le impostazioni appropriate in base ai requisiti della soluzione. È inoltre possibile utilizzare il controllo PassiveFederationSignIn anziché FAM come illustrato in di Figura 3. Il controllo sia possibile caricare le impostazioni nella sezione microsoft.identityModel oppure è possibile impostare le proprietà direttamente nel controllo.

Il controllo è utile se si desidera che le richieste non autorizzate per essere reindirizzati a una pagina di accesso in cui l'utente può esplicitamente Accedi facendo clic sul controllo, anziché dover FAM di reindirizzare automaticamente il servizio STS. Ad esempio se l'utente può appartenere a più di un provider di identità (area di autenticazione principale), la pagina di accesso potrebbe fornire un meccanismo per utente indicare la propria area di autenticazione principale prima per reindirizzare il servizio STS. Individuazione dell'area di autenticazione principale verrà illustrato tra breve.

Emissione token passivo

Come accennato in precedenza, la federazione passiva si basa su reindirizzamenti HTTP GET e POST e browser per facilitare la comunicazione tra RP e STS. Figura 6 Mostra i parametri di richiesta primaria coinvolti nella richiesta di accesso e risposta di segno durante questo processo.

Figura 6 primario Sign-in Request e Response parametri coinvolti nelle richieste di federazione passiva

Quando il servizio STS riceve la richiesta di accesso, verificherà che che conosce il RP controllando il parametro wtrealm confrontato con l'elenco delle aree di autenticazione RP noti. Il servizio STS avrà probabilmente conoscenza di RP, il certificato richiesto per il token di crittografia e le aspettative rispetto alle attestazioni desiderate da includere nel token rilasciato. Il RP può indicare che dichiara che richiede se viene fornito il parametro facoltativo wreq con una richiesta completa Accedi e il servizio STS può facoltativamente rispettano tale elenco o decidere autonomamente quale dichiara di concedere in base all'utente autenticato.

In uno scenario di federazione semplice come quella descritta in Figura 1 , è presente un unico RP e un STS IP unico responsabile per l'autenticazione degli utenti. Se IP-STS autentica gli utenti in un dominio Windows, esso potrebbe rilasciare attestazioni ruolo Admin, User o Guest. Il presupposto è che questi ruoli hanno significato per RP per l'autorizzazione. Nella sezione successiva verranno presuppongono questi ruoli sono sufficienti e illustrano le tecniche di autorizzazione. Dopo che illustrerò trasformazione di attestazioni a RP convertire STS attestazioni in un formato più utile per l'autorizzazione, se necessario.

Autorizzazione basata sulle attestazioni

Come ho spiegato nel mio articolo precedente, protezione basata sui ruoli in .NET Framework è previsto che un'identità di protezione è associata a ciascun thread. L'identità di protezione basato su IPrincipal, include l'identità dell'utente autenticato in un'implementazione IIdentity. WIF fornisce ClaimsPrincipal e ClaimsIdentity tipi basati su IClaimsPrincipal e IClaimsIdentity (che derivano indirettamente da IPrincipal e IIdentity). Quando il FAM elabora la risposta di segno, hydrates un ClaimsPrincipal per il token di protezione emesso. Analogamente, il SAM hydrates un ClaimsPrincipal per il cookie di sessione. Questo ClaimsPrincipal è il cuore di WIF autorizzazione per un'applicazione ASP.NET.

È possibile utilizzare uno dei seguenti approcci all'autorizzazione:

• Utilizzare le impostazioni di autorizzazione specifici per la località per limitare l'accesso a directory o risorse singole applicazioni.
• Utilizzare i controlli di accesso ASP.NET, ad esempio il controllo LoginView, per controllare l'accesso alle funzionalità.
• Utilizzare ClaimsPrincipal per eseguire i controlli dinamici IsInRole (ad esempio, per nascondere o mostrare elementi dell'interfaccia utente dinamicamente).
• Utilizzare il tipo di PrincipalPermission per eseguire le richieste di autorizzazione dinamico o l'attributo PrincipalPermissionAttribute se la richiesta di autorizzazione dichiarative sembra appropriata su un particolare metodo.
• Forniscono un ClaimsAuthorizationManager personalizzato per centralizzare l'accesso ai controlli in un singolo componente, anche prima di caricare la risorsa richiesta.

I primi tre di queste opzioni si basano sul metodo IsInRole esposto dal tipo ClaimsPrincipal. È necessario selezionare un ruolo attestazione tipo adattamento per controllo IsInRole in modo che le attestazioni corrette verranno utilizzate per controllare l'accesso. Il tipo di attestazione di ruoli predefinito per WIF è:

https://schemas.microsoft.com/ws/2008/06/identity/claims/role

Se ClaimsPrincipal include le attestazioni definite, il tipo di attestazione ruolo corrisponderanno predefinito. In seguito, verranno descritte le attestazioni di autorizzazione nel contesto della trasformazione di attestazioni. Quando questi vengono utilizzati, è necessario specificare il tipo di attestazione di autorizzazione del tipo di attestazione ruolo affinché IsInRole saranno effettive.

È possibile controllare l'accesso a pagine specifiche o directory globale dal file web.config. Fornire un tag di posizione specifica il percorso da proteggere, un elenco di ruoli accettabili Consenti e Nega l'accesso a tutti gli utenti nella radice dell'applicazione. Il seguente consente solo agli amministratori di accedere ai file nella directory AdminOnly:

<location path="AdminOnly">
  <system.web>
    <authorization>
      <allow roles="Administrators" />
      <deny users="*"/>
    </authorization>
  </system.web>
</location>

In alternativa, è possibile inserire un file web.config in qualsiasi sottodirectory e specificare le regole di autorizzazione. Inserire la seguente configurazione nella directory AdminOnly raggiunge lo stesso risultato:

<configuration>
  <system.web>
    <authorization >
      <allow roles="Administrators" />
      <deny users="*"/>
    </authorization>
  </system.web>
</configuration>

Per nascondere in modo dinamico e mostrano i componenti dell'interfaccia utente o controllare l'accesso alle funzionalità all'interno di una pagina, è possibile sfruttare le funzionalità dei controlli, ad esempio il LoginView basata sui ruoli. Tuttavia, la maggior parte degli sviluppatori preferiscono impostare esplicitamente le proprietà per il controllo di accesso durante la pagina Carica per un controllo più capillare del controllo. A tale scopo, è possibile chiamare il metodo IsInRole esposto da attestazioni ­ principale. È possibile accedere all'oggetto principal corrente tramite la proprietà statica thread.CurrentPrincipal come segue:

if (!Thread.CurrentPrincipal.IsInRole("Administrators"))
  throw new SecurityException("Access is denied.");

Oltre ai controlli IsInRole espliciti in fase di esecuzione, è inoltre possibile scrivere le richieste di autorizzazione basata sui ruoli classico utilizzando Principal ­ tipo di autorizzazione. Inizializzazione di tipo con l'attestazione di ruolo obbligatorio (il secondo parametro del costruttore) e quando viene chiamata la richiesta, viene chiamato il metodo IsInRole dell'oggetto principal corrente. Se la richiesta non viene trovato, viene generata un'eccezione:

PrincipalPermission p = 
  new PrincipalPermission("", "Administrators");
p.Demand();

Questo approccio è utile per rifiutare una richiesta con un'eccezione quando non sono presenti i ruoli appropriati.

È inoltre utile centralizzare i controlli di autorizzazione comuni a tutte le risorse richieste. In alcuni casi, se si dispone di un criterio di controllo di accesso, ad esempio le regole memorizzate in un database, è possibile utilizzare un componente centrale per leggere tali regole per controllare l'accesso alle funzionalità. A questo scopo, WIF fornisce un componente ClaimsAuthorizationManager che è possibile estendere. Richiamare dal mio articolo precedente che è possibile configurare questo tipo di componente personalizzato nella sezione modello di identità:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <claimsAuthorizationManager 
      type="CustomClaimsAuthorizationManager"/>
  </service>
</microsoft.identityModel>

Figura 7 illustra un ClaimsAuthorizationManager personalizzato che verifica la presenza dell'attestazione nome e indica se la risorsa richiesta è all'interno della directory AdminsOnly richiede l'attestazione del ruolo Administrators.

Figura 7 di implementazione ClaimsAuthorizationManager personalizzata

public class CustomClaimsAuthorizationManager: 
  ClaimsAuthorizationManager {

  public CustomClaimsAuthorizationManager()
  { }

  public override bool CheckAccess(
    AuthorizationContext context) {

    ClaimsIdentity claimsIdentity = 
      context.Principal.Identity as ClaimsIdentity;
    if (claimsIdentity.Claims.Where(
      x => x.ClaimType == ClaimTypes.Name).Count() <= 0)
      throw new SecurityException("Access is denied.");
        
    IEnumerable<Claim> resourceClaims = 
      context.Resource.Where(x=>x.ClaimType==ClaimTypes.Name);
    if (resourceClaims.Count() > 0) {
      foreach (Claim c in resourceClaims) {
        if (c.Value.Contains("\AdminOnly") && 
          !context.Principal.IsInRole("Administrators"))
          throw new SecurityException("Access is denied.");
      }
    }

    return true;
  }
}

Il CustomClaimsAuthorizationManager Ignora controllo ­ Access per fornire questa funzionalità. Questo metodo fornisce un parametro AuthorizationContext, che fornisce informazioni sull'azione richiesta (per la federazione passiva questo è un verbo HTTP, ad esempio GET o POST), la risorsa richiesta (URI) e le attestazioni ­ principale, non è ancora associato al thread di richiesta.

Trasformazione delle attestazioni

Spesso, le attestazioni emesse da STS IP, sebbene utili per descrivere l'utente autenticato, non sono rilevanti per i requisiti di autorizzazione del RP. Non è processo di IdP sapere quale tipo di ruoli, autorizzazioni o altri elementi specifici è necessario per l'autorizzazione a ogni RP. È compito del IdP concedere reclami relativi al dominio del provider di identità, controversie relative all'utente autenticato può asserire l'IdP.

La RP, potrebbe essere necessario trasformare le attestazioni da IP-STS qualcosa di più rilevanti per l'autorizzazione. Ciò implica che il RP può mappare l'identità dell'utente (ad esempio, nome utente o nome principale utente) a un set di attestazioni RP. Supponendo che le attestazioni IP STS concede predefinite ruolo, Figura 8 elenchi un set di autorizzazioni possibile afferma che la RP può emettere basato su ogni attestazione di ruolo in ingresso. Tipo di attestazione dell'autorizzazione potrebbe essere un tipo di attestazione personalizzato definito per la RP come:

urn:ClaimsAwareWebSite/2010/01/claims/permission

Un buon punto di trasformazione delle attestazioni IP STS in ingresso è un ClaimsAuthenticationManager personalizzato. È possibile installare un ClaimsAuthenticationManager personalizzato aggiungendo quanto segue alla sezione microsoft.identityModel:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <claimsAuthenticationManager 
      type="CustomClaimsAuthenticationManager"/>
  </service>
</microsoft.identityModel>

Figura 9 Mostra un esempio CustomClaimsAuthenticationManager trasforma in ingresso attestazioni ruolo consentite dall'IP-STS nell'autorizzazione attestazioni rilevanti per la RP.

Figura 8 trasformazione dei ruoli richiede di attestazioni di autorizzazione con il RP

Figura 9 di trasformazione attestazioni personalizzate alla RP

public class CustomClaimsAuthenticationManager: 
  ClaimsAuthenticationManager {

  public CustomClaimsAuthenticationManager() { }

  public override IClaimsPrincipal Authenticate(
    string resourceName, IClaimsPrincipal incomingPrincipal) {

    IClaimsPrincipal cp = incomingPrincipal;
    ClaimsIdentityCollection claimsIds = 
      new ClaimsIdentityCollection();

    if (incomingPrincipal != null && 
      incomingPrincipal.Identity.IsAuthenticated == true) {

      ClaimsIdentity newClaimsId = new ClaimsIdentity(
        "CustomClaimsAuthenticationManager", ClaimTypes.Name, 
        "urn:ClaimsAwareWebSite/2010/01/claims/permission");

      ClaimsIdentity claimsId = 
        incomingPrincipal.Identity as ClaimsIdentity;
      foreach (Claim c in claimsId.Claims)
        newClaimsId.Claims.Add(new Claim(
          c.ClaimType, c.Value, c.ValueType, 
          "CustomClaimsAuthenticationManager", c.Issuer));

      if (incomingPrincipal.IsInRole("Administrators")) {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Create"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Update"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Delete"));
      }

      else if (incomingPrincipal.IsInRole("Users")) {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Create"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Update"));
      }

      else {
        newClaimsId.Claims.Add(new Claim(
          "urn:ClaimsAwareWebSite/2010/01/claims/permission", 
          "Read"));
      }

      claimsIds.Add(newClaimsId);
      cp = new ClaimsPrincipal(claimsIds);
    }

    return cp;
  }
}

Per verifiche IsInRole (come descritto in precedenza) per funzionare, è necessario fornire il tipo di attestazione dell'autorizzazione come tipo di attestazione del ruolo. Di Figura 9, viene specificato quando viene costruito il ClaimsIdentity perché il RP consiste nella creazione di ClaimsIdentity.

Nel caso in cui i token SAML in ingresso sono l'origine delle attestazioni, è possibile fornire il tipo di attestazione di ruolo per il SecurityTokenHandler. Di seguito viene illustrato come configurare in modo dichiarativo Saml11SecurityTokenHandler utilizzare il tipo di attestazione dell'autorizzazione come tipo di attestazione del ruolo:

<microsoft.identityModel>
  <service>
    <!--other settings-->
    <securityTokenHandlers>
      <remove type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <samlSecurityTokenRequirement >
          <roleClaimType 
            value= "urn:ClaimsAwareWebSite/2010/01/claims/permission"/>
        </samlSecurityTokenRequirement>
      </add>
    </securityTokenHandlers>
  </service>
</microsoft.identityModel>

Gestori di token SAML contiene una sezione samlSecurityTokenRequirement dove è possibile specificare un'impostazione per il nome e ruolo attestazione tipo con altre impostazioni relative alla convalida dei certificati e i token di Windows.

Rilevamento Realm home

Finora ho particolare uno scenario semplice la federazione con un STS IP singolo. Il presupposto è che il RP reindirizzerà sempre un STS IP specifico per l'autenticazione degli utenti.

Nel mondo della federazione, tuttavia la RP potrebbe attendibilità più autorità emittenti token da domini diversi. Una nuova sfida presenta solo in questo caso perché il RP deve decidere quali IP STS deve autenticare gli utenti che richiedono l'accesso alle risorse. Il dominio a cui autenticare gli utenti è nota come area di autenticazione principale dell'utente e pertanto questo processo è denominato individuazione dell'area di autenticazione principale.

Esistono numerosi meccanismi di che un'applicazione può utilizzare per l'individuazione dell'area di autenticazione principale:

• Come nell'esempio corrente dell'area di autenticazione principale è noto richieste avanzate e così sempre vengono reindirizzate a un STS IP specifico.
• Gli utenti possono individuare il RP da un altro portale, in grado di fornire una stringa di query per indicare l'area di autenticazione principale per gli utenti dal portale.
• Il RP potrebbero richiedere tale terreno di utenti in una pagina particolare voce per ogni area di autenticazione principale. La pagina di destinazione può assumere una particolare area di autenticazione principale.
• Il RP potrebbe essere in grado di determinare l'area di autenticazione principale tramite l'indirizzo IP della richiesta o alcuni altri euristica.
• Se il RP può determinare l'area di autenticazione principale da una delle tecniche sopra menzionate, esso può presentare un'interfaccia utente in cui è possibile selezionare l'area di autenticazione principale oppure fornire informazioni che consentano di RP stabilirlo.
• Se il RP supporta le schede informazioni, la carta selezionata può unità autenticazione all'area principale appropriato tramite federazione attiva.
• Il WS-Federation descrive brevemente come uno potrebbe implementare un servizio di individuazione per la risoluzione dell'area di autenticazione principale, ma non è una specifica ben definita.

Indipendentemente da come viene scoperta l'area di autenticazione principale, l'obiettivo consiste nel reindirizzare l'utente da autenticare con IP corretto-STS. Esistono alcuni possibili scenari qui. In uno scenario di RP potrebbe essere necessario impostare in modo dinamico l'emittente URI in modo che la richiesta di accesso viene inviata a IP corretto-STS. Sono in questo caso, la RP deve elencati STS IP attendibili tutti nella sezione trustedIssuers, ad esempio:

<trustedIssuers>
  <add thumbprint="6b887123330ae8d26c3e2ea3bb7a489fd609a076" 
    name="IP1" />
  <add thumbprint="d5bf17e2bf84cf2b35a86ea967ebab838d3d0747" 
    name="IP2" />
</trustedIssuers>

È possibile, inoltre, l'override dell'evento RedirectingToIdentityProvider esposta tramite il FAM e tramite l'euristica pertinenti, determinare l'URI per il servizio STS. A tale scopo, inserire il seguente codice nell'implementazione di Global.asax:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
  object sender, RedirectingToIdentityProviderEventArgs e) {
  if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP1RealmEntry.aspx")) {
    e.SignInRequestMessage.BaseUri = 
      new Uri("https://localhost/IP1/STS/Default.aspx");
  }
  else if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP2RealmEntry.aspx")) {
    e.SignInRequestMessage.BaseUri = new Uri(
       "https://localhost/IP2/STS/Default.aspx");
  }
}

Altro scenario prevede passando il parametro dell'area di autenticazione principale (whr) con la richiesta di accesso per il servizio STS primario. Il RP potrebbe, ad esempio, avere una risorsa STS (R STS o RP STS) responsabile della trasformazione di attestazioni. RP-STS non autenticare gli utenti (non un IdP), ma ha relazioni di trust con altri IdPs.

Il RP ha una relazione di trust con RP-STS e rispetteranno sempre token rilasciato da RP-STS. RP-STS è responsabile del reindirizzamento IdP corretto per ogni richiesta. RP-STS può determinare STS IP corrette per reindirizzare come nel codice appena descritto, ma è un'altra opzione per RP fornire informazioni sull'area di autenticazione principale, questo passaggio nel parametro dell'area di autenticazione principale RP-STS. In questo caso, la RP imposta dinamicamente il parametro principale dell'area di autenticazione:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(
  object sender, RedirectingToIdentityProviderEventArgs e) {
  if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP1RealmEntry.aspx")) {
    e.SignInRequestMessage.HomeRealm = 
      "https://localhost/IP1/STS/Default.aspx";
  }
  else if (e.SignInRequestMessage.RequestUrl.Contains(
    "IP2RealmEntry.aspx")) {
    e.SignInRequestMessage.HomeRealm = 
      "https://localhost/IP2/STS/Default.aspx";
  }
}

RP-STS utilizza questo parametro per reindirizzare il STS IP corretto e successivamente trasforma le attestazioni da IP-STS in attestazioni rilevanti per la RP.

Single Sign-on e Single Esci

Single Sign-on e uscita singola sono componenti importanti di federazione. È una funzionalità che consente agli utenti autenticati di accedere a più applicazioni RP durante una sola volta l'autenticazione Single Sign-on. Singola uscita, come implica, facilita uscita da tutte le applicazioni RP e qualsiasi catena STS rilevante con una singola richiesta.

In una federazione semplice scenario come quello illustrato nella Figura 1 , l'utente autentica IP-STS e autorizzato a RP in base al token di protezione emesso. Post-Authentication, l'utente è un cookie di sessione per il servizio STS e un altro per la RP. A questo punto, se l'utente accede a un altro RP, Maria verrà reindirizzata il servizio STS IP per l'autenticazione, supponendo che entrambe le applicazioni RP trust IP stesso-STS. Perché l'utente dispone già di una sessione con IP-STS, il servizio STS emetterà un token per il secondo RP senza richiedere credenziali. L'utente ha accesso RP secondo ora e dispone di un cookie di sessione nuova per la seconda RP.

Come ho spiegato, WIF fornisce il SAM per scrivere il cookie di sessione per utenti autenticati. Per impostazione predefinita, il cookie di sessione viene emesso per l'indirizzo relativo dell'applicazione per il dominio e il nome di base è FedAuth. Poiché i cookie di sessione federato possono essere elevati, il token in genere è suddiviso in due (o più) cookie: FedAuth, FedAuth1 e così via.

Se si ospitano più applicazioni nel dominio stesso, come parte dello scenario federazione, il comportamento predefinito sarà il browser dispone di un cookie FedAuth per ogni RP (vedere di Figura 10). Il browser invia solo tali cookie associati al dominio e al percorso della richiesta.

Figura 10 cookie di sessione associato a ogni RP e il servizio STS

Questo comportamento è in genere bene, ma a volte è necessario fornire un nome univoco per ogni applicazione di ciascun cookie di sessione, in particolare se si sta ospitati nello stesso dominio. O più applicazioni dello stesso dominio possono condividere un cookie di sessione, nel qual caso è possibile impostare il percorso del cookie “ / ”.

Se il cookie di sessione scade, il browser verrà rimosso dalla cache e l'utente verrà reindirizzato nuovamente il servizio STS per l'autenticazione. Separatamente, il token rilasciato associato il cookie di sessione scaduto, WIF verrà reindirizzata a STS un nuovo token.

Uscita è più esplicita, in genere gestita dall'utente. Singola uscita è una funzionalità facoltativa della specifica WS-Federation suggerisce il servizio STS necessario avvisare comunque anche altre applicazioni RP che ha emesso i token della richiesta in uscita. In questo modo il cookie della sessione viene rimosso per tutte le applicazioni utente esplorato per durante la sessione. In uno scenario più complesso, in cui sono coinvolti più STSs, il servizio STS principale riceve la richiesta di uscita devono notificare anche altri STSs fare lo stesso.

Ai fini di questa discussione, mi concentrerò sulle operazioni in RP per facilitare l'uscita federato singolo. È possibile inserire il controllo FederatedPassiveSignInStatus in qualsiasi pagina dalla quale si desidera supportare Accedi e uscita e indicherà automaticamente lo stato del controllo. Una volta firmati aggiuntivo, il controllo presenta un collegamento, pulsante o un'immagine per la firma.

Quando si seleziona il controllo, gestirà uscita in base alla proprietà SignOutAction, ovvero aggiorna, reindirizzamento, RedirectToLoginPage o FederatedPassiveSignOut. I primi tre eliminare il cookie di sessione per l'applicazione, ma non inviano il servizio STS della richiesta in uscita. Quando si seleziona l'impostazione FederatedPassiveSignOut, quest'ultimo chiamerà SignOut WSFederationAuthenticationModule. Ciò garantisce che vengano rimossi i cookie di sessione federati per l'applicazione. Inoltre, viene inviata una richiesta di uscita per il servizio STS:

GET https://localhost/IP1/STS?wa=wsignout1.0

Se non si utilizzano il controllo FederatedPassiveSignInStatus, è possibile chiamare direttamente WSFederationAuthenticationModule.SignOut per attivare un reindirizzamento al servizio STS con la richiesta in uscita.

Singola uscita implica che l'utente viene disconnesso da tutte le applicazioni che ha effettuata l'identità federata. Se il servizio STS supporta questo, dovrà contenere un elenco di applicazioni RP utente connesso durante la sessione e problema viene richiesta una richiesta di pulizia per ogni RP quando federati uscita:

GET https://localhost/ClaimsAwareWebSite?wa=wsignoutcleanup1.0

In scenari più complessi, la stessa richiesta di pulizia necessario inviare qualsiasi altro STS coinvolta nella sessione di federata.A tal fine, il servizio STS sarebbe stato conoscenza dell'URI pulizia per ogni RP e STS.Per supportare solo uscita, il RPs deve essere in grado di elaborare le richieste di pulitura.Supporto di FAM e controllo FederatedPassiveSignInStatus.Se si utilizza il FAM, la richiesta di pulitura può essere registrata al RP qualsiasi URI e il FAM verrà elabora la richiesta e ripulire i cookie di sessione.Se si utilizza il controllo FederatedPassiveSignInStatus, la richiesta di pulitura deve essere registrata in una pagina che contiene il controllo.

Specifica WS-Federation, infatti, non in dettaglio come implementare il comportamento di uscita e pulizia singolo oltre le stringhe di query consigliata e il flusso della comunicazione.Non è facile garantisce solo uscita sia efficacia tra tutti i partner di federazione di conseguenza, se si è proprietari dell'ambiente e si desidera raggiungere questo obiettivo, è effettivamente possibile.

Michele Leroux Bustamante è architetto responsabile in IDesign (idesign.net) e architetto responsabile protezione all'indirizzo BiTKOOs (bitkoo.com). È inoltre un direttore regionale Microsoft per San Diego e MVP Microsoft per sistemi connessi. Visitare il suo blog all'indirizzo dasblonde.net.

Grazie all'esperto di tecnica seguente per la revisione di questo articolo: Govind Ramanathan