Condividi tramite

Scenari non supportati

  • Articolo

Per vari motivi, Windows Communication Foundation (WCF) non supporta alcuni scenari di sicurezza specifici. Ad esempio, i protocolli di autenticazione SSPI e Kerberos non sono implementati in Windows XP Home Edition. Pertanto, in WCF l'esecuzione dei servizi che utilizzano l'autenticazione di Windows su questa piattaforma non è supportata. Altri meccanismi di autenticazione, ad esempio l'autenticazione integrata basata su nome utente/password e HTTP/HTTPS, sono supportati se WCF viene eseguito in Windows XP Home Edition.

Scenari di rappresentazione

L'identità rappresentata potrebbe non fluire quando i client effettuano chiamate asincrone

Quando un client WCF effettua chiamate asincrone a un servizio WCF utilizzando l'autenticazione di Windows sotto rappresentazione, potrebbe verificarsi l'autenticazione con l'identità del processo client anziché con l'identità rappresentata.

In WCF non è supportata la rappresentazione e quando sussistono le condizioni elencate di seguito viene generata un'eccezione InvalidOperationException:

  • Il sistema operativo è Windows XP.

  • La modalità di autenticazione genera un'identità Windows.

  • La proprietà Impersonation del OperationBehaviorAttribute è impostata su Required.

  • Viene creato un token del contesto di sicurezza SCT (Security Context Token) basato sullo stato. Per impostazione predefinita, la creazione è disattivata.

Il token SCT basato sullo stato può essere creato solo tramite un'associazione personalizzata. Per altre informazioni, vedere: Procedura: Creare un token di contesto di sicurezza per una sessione sicura. In codice, per attivare il token occorre creare un elemento di associazione di sicurezza (SymmetricSecurityBindingElement o AsymmetricSecurityBindingElement) utilizzando il metodo SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) o il metodo SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) e impostando il parametro requireCancellation su false. Il parametro fa riferimento alla memorizzazione nella cache del token SCT. L'impostazione del valore su false comporta l'attivazione della funzionalità del token SCT basato sullo stato.

In alternativa, per abilitare il token nella configurazione, è necessario creare un <customBinding> e quindi aggiungere un elemento <security> e impostare l'attributo authenticationMode su SecureConversation e l'attributo requireSecurityContextCancellation su true.

Nota

I requisiti precedenti sono specifici. Ad esempio, il metodo CreateKerberosBindingElement crea un elemento di associazione che genera un'identità Windows senza tuttavia creare un token SCT. È pertanto possibile utilizzare questa identità con l'opzione Required di Windows XP.

Possibile conflitto con ASP.NET

WCF e ASP.NET possono entrambi attivare o disattivare la rappresentazione. Quando ASP.NET ospita un'applicazione WCF, potrebbe esistere un conflitto tra le impostazioni di configurazione WCF e quelle di ASP.NET. In caso di conflitto, l'impostazione di WCF ha la precedenza, a meno che la proprietà Impersonation sia impostata su NotAllowed. In questo caso, l'impostazione della rappresentazione ASP.NET ha la precedenza.

Possibilità di esito negativo dei caricamenti dell'assembly in caso di utilizzo della rappresentazione

Se il contesto rappresentato non dispone delle autorizzazioni di accesso per caricare un assembly e se è la prima volta che il Common Language Runtime (CLR) tenta di caricare l'assembly per tale dominio applicazione, il dominio AppDomain memorizza l'errore nella cache. I tentativi successivi di caricamento dell'assembly (o degli assembly) hanno esito negativo, anche dopo aver ripristinato la rappresentazione e anche se il contesto ripristinato dispone delle autorizzazioni di accesso per caricare l'assembly. Ciò è dovuto al fatto che CLR non esegue nuovi tentativi di caricamento dopo che il contesto utente è cambiato. Per risolvere il problema è necessario riavviare il dominio applicazione.

Nota

Il valore predefinito della proprietà AllowedImpersonationLevel della classe WindowsClientCredential è Identification. Nella maggior parte dei casi, un contesto di rappresentazione a livello di identificazione non dispone di alcun diritto che consenta il caricamento di assembly aggiuntivi. Poiché si tratta di un valore predefinito, questo caso risulta essere molto comune e merita particolare attenzione. La rappresentazione a livello di identificazione si verifica anche quando il processo di rappresentazione non dispone del privilegio SeImpersonate. Per altre informazioni, vedere Delega e rappresentazione.

Requisito di negoziazione della credenziale in caso di delega

Per poter essere utilizzato con la funzionalità di delega, il protocollo di autenticazione Kerberos deve essere implementato con la negoziazione delle credenziali. Questa versione di Kerberos è talvolta nota come Kerberos multifase. Se si implementa l'autenticazione Kerberos senza negoziazione delle credenziali (ovvero una versione di Kerberos anche nota come monofase o monopassaggio), verrà generata un'eccezione. Per altre informazioni su come implementare la negoziazione delle credenziali, vedere Debug degli errori di autenticazione di Windows.

Crittografia

Supporto di SHA-256 solo in caso di utilizzo di chiavi simmetriche

WCF supporta diversi algoritmi di crittografia e di creazione di digest di firme che è possibile specificare utilizzando la suite di algoritmi disponibile nelle associazioni fornite dal sistema. Per implementare un meccanismo di sicurezza avanzata, WCF supporta gli algoritmi Secure Hash Algorithm (SHA) 2, in particolare l'algoritmo SHA-256, per creare hash digest di firme. Questa versione supporta l'algoritmo SHA-256 solo nei casi in cui si utilizzano chiavi simmetriche, ad esempio le chiavi Kerberos, e nei casi in cui i messaggi non vengono firmati tramite un certificato X.509. WCF non supporta le firme RSA (utilizzate nei certificati X.509) con l'hash SHA-256 in quanto al momento non supporta l'algoritmo RSA-SHA256.

Mancanza del supporto per gli hash SHA-256 conformi agli standard FIPS

WCF non supporta gli hash SHA-256 conformi agli standard FIPS. Pertanto, WCF non supporta le suite di algoritmi basate su SHA-256 nei sistemi che richiedono l'utilizzo di algoritmi conformi agli standard FIPS.

Possibilità di esito negativo degli algoritmi conformi agli standard FIPS in caso di modifica del Registro di sistema

Lo snap-in Impostazioni protezione locale di Microsoft Management Console (MMC) consente di attivare e disattivare gli algoritmi conformi agli standard FIPS. Questa impostazione può inoltre essere eseguita nel Registro di sistema. Si noti tuttavia che WCF non supporta l'utilizzo del Registro di sistema per reimpostare l'impostazione. Se si esegue questa impostazione utilizzando un valore diverso da 1 oppure 0 è possibile che si verifichino risultati incoerenti tra il runtime CLR e il sistema operativo.

Restrizione sulla crittografia AES conforme agli standard FIPS

La crittografia AES conforme agli standard FIPS non funziona nei callback duplex nel contesto di una rappresentazione di livello di identificazione.

Certificati CNG/KSP

Cryptography API: Next Generation (CNG) è la sostituzione a lungo termine di CryptoAPI. Questa API è disponibile in codice non gestito in Windows Vista, Windows Server 2008 e versioni successive di Windows.

.NET Framework 4.6.1 e versioni precedenti non supportano questi certificati perché usano CryptoAPI legacy per gestire i certificati CNG/KSP. L'uso di questi certificati con .NET Framework 4.6.1 e versioni precedenti causerà un'eccezione.

Esistono due modi possibili per stabilire se un certificato utilizza KSP:

Errore di sicurezza a livello di messaggio quando si utilizza la rappresentazione ASP.NET e la compatibilità con ASP.NET è obbligatoria

WCF non supporta la combinazione seguente di condizioni, in quanto può impedire lo svolgimento dell'autenticazione client:

  • È stata attivata la rappresentazione ASP.NET. A questo scopo, nel file Web.config impostare l'attributo impersonate dell'elemento <identity> su true.

  • La modalità di compatibilità ASP.NET è abilitata impostando l'attributo aspNetCompatibilityEnabled di <serviceHostingEnvironment> su true.

  • Viene utilizzata la protezione a livello di messaggio.

Per risolvere questo problema è sufficiente disattivare la modalità di compatibilità con ASP.NET. In alternativa, se la modalità di compatibilità con ASP.NET è obbligatoria, è possibile disattivare la funzionalità di rappresentazione ASP.NET e utilizzare invece la rappresentazione fornita in WCF. Per altre informazioni, vedere Delega e rappresentazione.

Errore di indirizzo letterale IPv6

Le richieste di sicurezza hanno esito negativo quando il client e il servizio si trovano nello stesso computer e gli indirizzi letterali Ipv6 vengono utilizzati per il servizio.

Gli indirizzi di questo tipo funzionano se il servizio e il client sono sui computer diversi.

Errori di recupero di WSDL con trust federati

WCF richiede esattamente un documento WSDL per ogni nodo nella catena di trust federati. È opportuno prestare attenzione a non impostare un ciclo quando si specificano gli endpoint. È possibile che si verifichi un ciclo quando si utilizza un download WSDL di catene di trust federati con due o più collegamenti nello stesso documento WSDL. Uno scenario comune in cui può verificarsi questo problema consiste in un servizio federato in cui il server di token di sicurezza e il servizio sono contenuti nello stesso ServiceHost.

Un esempio di questa situazione è dato da un servizio con i tre indirizzi endpoint seguenti:

  • http://localhost/CalculatorService/service (il servizio)

  • http://localhost/CalculatorService/issue_ticket (l'STS)

  • http://localhost/CalculatorService/mex (l'endpoint dei metadati)

Viene generata un'eccezione.

È possibile risolvere questo scenario collocando l'endpoint issue_ticket in un'altra posizione.

Gli attributi di importazione di WSDL possono andare persi

In WCF si perde traccia degli attributi in un elemento <wst:Claims>RST in un modelloRST quando viene eseguita un'importazione WSDL. Questa situazione si verifica durante un'importazione WSDL se si specifica WSFederationHttpBinding.Security.Message.TokenRequestParameters direttamente in<Claims>IssuedSecurityTokenRequestParameters.AdditionalRequestParameters o inWSFederationHttpBinding.Security.Message.TokenRequestParameters anziché utilizzare direttamente le raccolte dei tipi di attestazione. Poiché l'importazione perde gli attributi, l'associazione non esegue correttamente una sequenza di andata e ritorno attraverso WSDL e quindi risulta errata sul lato client.

Per risolvere il problema è necessario modificare l'associazione direttamente nel client dopo aver eseguito l'importazione.

Vedi anche