Condividi tramite

Scenari non supportati

  • Articolo

Per varie ragioni, Windows Communication Foundation (WCF) non supporta alcuni scenari di protezione 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

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 di OperationBehaviorAttribute è impostata su Required.
  • Viene creato un token del contesto di protezione 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 ulteriori informazioni, vedere Procedura: creare un token di contesto di protezione con stato per una sessione protetta.) In codice, per attivare il token occorre creare un elemento di associazione di protezione (SymmetricSecurityBindingElement o AsymmetricSecurityBindingElement) utilizzando il metodo System.ServiceModel.Channels.SecurityBindingElement.CreateSspiNegotiationBindingElement(System.Boolean) o il metodo System.ServiceModel.Channels.SecurityBindingElement.CreateSecureConversationBindingElement(System.ServiceModel.Channels.SecurityBindingElement,System.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 configurazione, per attivare il token è invece necessario creare un'associazione <customBinding>, aggiungere un elemento <security> e infine 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 è possibile che si verifichi un conflitto tra le impostazioni di configurazione di WCF e 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 ulteriori informazioni, vedere Delega e rappresentazione con WCF.

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 l'autenticazione Kerberos viene implementata senza negoziazione delle credenziali (versione di Kerberos anche nota come monofase), viene generata un'eccezione. Per ulteriori informazioni sulla modalità di implementazione della 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 protezione 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. Quando si utilizza l'hash SHA-256, WCF non supporta le firme RSA (utilizzate nei certificati X.509) in quanto al momento .NET Framework 3.0 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 in Windows Server 2008

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

Su piattaforme legacy (Windows Server 2003 e Windows XP) .NET Framework 2.0 non riconosce questo protocollo e utilizza il protocollo CryptoAPI preesistente per gestire i certificati CNG/KSP. In Windows Server 2008 e Windows Vista .NET Framework 3.5 non supporta questi certificati: il loro utilizzo genera un'eccezione.

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

Errore di protezione 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. Per eseguire questa operazione occorre accedere al file Web.config e quindi impostare l'attributo impersonate dell'elemento <identity> su true.
  • È stata impostata la modalità di compatibilità con ASP.NET. Per eseguire questa operazione occorre impostare l'attributo aspNetCompatibilityEnabled dell'<serviceHostingEnvironment> element 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 ulteriori informazioni, vedere Delega e rappresentazione con WCF.

Errore di indirizzo letterale IPv6

Le richieste di protezione 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 protezione e il servizio sono contenuti nello stesso ServiceHost.

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

  • https://localhost/CalculatorService/service (il servizio)
  • https://localhost/CalculatorService/issue_ticket (STS)
  • https://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> in un modello RST quando viene eseguita un'importazione WSDL. Questa situazione si verifica durante un'importazione WSDL se si specifica <Claims> direttamente in WSFederationHttpBinding.Security.Message.TokenRequestParameters o in IssuedSecurityTokenRequestParameters.AdditionalRequestParameters anziché utilizzare direttamente gli insiemi 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.

Vedere anche

Concetti

Diffusione di informazioni
Elevazione dei privilegi
Denial of Service (Negazione del servizio)
Manomissioni
Attacchi di tipo replay

Altre risorse

Considerazioni sulla protezione