Condividi tramite

Comportamenti di protezione in WCF

  • Articolo

In Windows Communication Foundation (WCF), i comportamenti determinano il ** funzionamento in fase di esecuzione a livello di servizio o a livello di endpoint. (Per ulteriori informazioni sui comportamenti in generale, vedere Specifica del comportamento in fase di esecuzione del servizio. I comportamenti di protezione consentono di controllare le credenziali, le autenticazioni, le autorizzazioni e i registri di controllo. I comportamenti possono essere utilizzati tramite programmazione o mediante configurazione. In questo argomento viene descritto come configurare i comportamenti relativi alle funzioni di protezione elencati di seguito:

Impostazione delle credenziali tramite i comportamenti

Utilizzare l'serviceCredentials element e l'clientCredentials element per impostare i valori delle credenziali di un servizio o di un client. La configurazione dell'associazione sottostante determina se occorre impostare una credenziale. Ad esempio, se la modalità di protezione è impostata su None, né i client né i servizi si autenticano reciprocamente o richiedono alcun tipo di credenziale.

Se invece l'associazione del servizio richiede un tipo di credenziale client, è possibile che occorra utilizzare un comportamento per impostare i valori delle credenziali. (Per ulteriori informazioni sui tipi esistenti di credenziali, vedere Selezione di un tipo di credenziale. In alcuni casi, ad esempio quando si esegue l'autenticazione tramite le credenziali di Windows, l'ambiente determina automaticamente i valori effettivi delle credenziali. Pertanto, a meno che non si desideri specificare un insieme diverso di credenziali, in questo caso non occorre eseguire l'impostazione manuale dei valori delle credenziali.

Tutte le credenziali di servizio si trovano nella serviceBehaviors section sottoforma di elementi figlio. L'esempio seguente illustra un certificato utilizzato come credenziale di servizio.

<configuration>
 <system.serviceModel>
  <behaviors>
   <serviceBehaviors>
    <behavior name="ServiceBehavior1">
     <serviceCredentials>
      <serviceCertificate findValue="000000000000000000000000000" 
                          storeLocation="CurrentUser"
      storeName="Root" x509FindType="FindByThumbprint" />
     </serviceCredentials>
    </behavior>
   </serviceBehaviors>
  </behaviors>
 </system.serviceModel>
</configuration>

Credenziali di servizio

L'<serviceCredentials> Element contiene quattro elementi figlio. Questi elementi e le relative modalità di utilizzo vengono descritti nelle sezioni seguenti.

Elemento <serviceCertificate>

Questo elemento consente di specificare il certificato X.509 utilizzato dai client per autenticare il servizio tramite la modalità di protezione Messaggio. L'identificazione personale di un certificato che viene rinnovato periodicamente viene anch'essa aggiornata periodicamente di conseguenza. In questo caso, poiché il certificato può essere rilasciato nuovamente con lo stesso nome del soggetto, utilizzare quest'ultimo come tipo X509FindType.

Per ulteriori informazioni sull'utilizzo dell'elemento, vedere Procedura: specificare valori di credenziali client.

Elemento <certificate> di <clientCertificate>

Utilizzare l'elemento <certificate> quando il servizio deve disporre in anticipo del certificato del client per poter comunicare in modo sicuro con quest'ultimo. Questa esigenza si presenta quando si utilizza il modello di comunicazione duplex. Nel modello più comune di comunicazione richiesta-risposta, il client include il proprio certificato nella richiesta e il servizio utilizza tale certificato per proteggere la risposta che invia al client. Il modello di comunicazione duplex, invece, non prevede né richieste né risposte e pertanto il servizio non può ricavare il certificato del client dalla comunicazione. Di conseguenza, per poter proteggere i messaggi inviati al client, il servizio deve disporre in anticipo del certificato del client. Questo certificato deve essere ottenuto mediante una modalità fuori banda e deve essere specificato tramite questo elemento. Per ulteriori informazioni sui servizi duplex, vedere Procedura: creare un contratto duplex.

Elemento <authentication> di <clientCertificate>

L'elemento <authentication> consente di personalizzare la modalità di autenticazione dei client. A tale scopo, l'attributo CertificateValidationMode può essere impostato su None, ChainTrust, PeerOrChainTrust, PeerTrust o Custom. Per impostazione predefinita, il livello è impostato su ChainTrust. Tale impostazione prevede che ogni certificato appartenga a una gerarchia di certificati che termina in un'autorità radice situata all'inizio della catena. Si tratta della modalità più sicura. Il livello può inoltre essere impostato su PeerOrChainTrust, a indicare che sia i certificati autocertificati (trust peer) sia i certificati appartenenti a una catena di trust sono ritenuti attendibili. Poiché i certificati autocertificati non devono essere acquistati da un'autorità attendibile, questo livello viene utilizzato in fase di sviluppo e di debug dei client e dei servizi. Quando si distribuisce un client è invece opportuno utilizzare il livello ChainTrust. Un altro livello disponibile è Custom. Quando si imposta il livello Custom è necessario impostare anche l'attributo CustomCertificateValidatorType sull'assembly e sul tipo utilizzati per convalidare il certificato. Per creare una convalida personalizzata è necessario ereditare una classe dalla classe astratta X509CertificateValidator.

Elemento <issuedTokenAuthentication>

L'emissione di un token di autenticazione prevede tre fasi. Nella prima fase, un client che tenta di accedere a un servizio viene reindirizzato a un servizio token di protezione (STS). Nella seconda fase, il servizio token di protezione autentica il client, quindi rilascia a quest'ultimo un token, in genere un token SAML (Security Assertions Markup Language), che il client restituisce in seguito al servizio. Nella terza fase, il servizio ricerca nel token appena ricevuto i dati da utilizzare per autenticare il token stesso e, pertanto, il client. Affinché il token venga autenticato è necessario che il servizio riconosca il certificato utilizzato dal servizio token di protezione. L'elemento <issuedTokenAuthentication> rappresenta il repository dei certificati utilizzati dal servizio token di protezione. Per aggiungere certificati, utilizzare l'<knownCertificates> element. Inserire un <add> element <knownCertificates> Element per ogni certificato, come illustrato nell'esempio seguente.

<issuedTokenAuthentication>
   <knownCertificates>
      <add findValue="www.contoso.com" 
           storeLocation="LocalMachine" storeName="My" 
           X509FindType="FindBySubjectName" />
    </knownCertificates>
</issuedTokenAuthentication>

Per impostazione predefinita, i certificati devono essere ottenuti da un servizio token di protezione. Questi certificati "riconosciuti" garantiscono che solo i client autorizzati siano in grado di accedere a un determinato servizio.

È necessario utilizzare l'insieme <allowedAudienceUris> in un'applicazione federata che utilizza un servizio token di protezione (STS) che emette token di protezione SamlSecurityToken. Al momento del rilascio del token di protezione, è possibile che il servizio STS specifichi l'URI dei servizi Web per i quali è destinato il token di protezione mediante l'aggiunta di un oggetto SamlAudienceRestrictionCondition al token di protezione. Ciò consente all'autenticatore SamlSecurityTokenAuthenticator del servizio Web di destinazione di verificare che il token di protezione emesso sia associato a questo servizio Web specificando che questo controllo deve essere svolto mediante l'esecuzione delle operazioni seguenti:

Per ulteriori informazioni, vedere SamlSecurityTokenAuthenticator.

Per ulteriori informazioni sull'utilizzo di questo elemento di configurazione, vedere Procedura: configurare le credenziali in un servizio federativo.

Autenticazione degli utenti anonimi di CardSpace

Se si imposta in modo esplicito l'attributo AllowUntrustedRsaIssuers dell'elemento <IssuedTokenAuthentication> su true, qualsiasi client è in grado di presentare un token autocertificato firmato con una coppia di chiavi RSA arbitraria. L'autorità emittente è considerata non attendibile, in quanto alla chiave non è stato associato alcun dato di autorità emittente. Un utente di CardSpace può creare una scheda autocertificata contenente attestazioni autonome di identità. Questa funzionalità deve essere utilizzata con cautela. Per utilizzare questa funzionalità, considerare la chiave RSA pubblica come una password dotata di un maggior livello di protezione da memorizzare in un database insieme a un nome utente. Prima di consentire a un client di accedere al servizio, verificare la chiave pubblica RSA presentata dal client confrontandola con la chiave pubblica memorizzata associata al nome utente presentato. Ciò presuppone l'implementazione di un processo di registrazione in base al quale un utente può registrare il proprio nome utente e associarlo alla chiave pubblica RSA autocertificata.

Credenziali client

Le credenziali client sono utilizzate per autenticare i client presso i servizi nei casi in cui non è richiesta l'autenticazione reciproca. È possibile utilizzare questa sezione per specificare i certificati di servizio negli scenari in cui il client deve utilizzare il certificato di un servizio per proteggere i messaggi inviati a quest'ultimo.

È inoltre possibile configurare un client come parte di uno scenario federativo in modo che utilizzi i token emessi da un servizio token di protezione o da un'autorità emittente locale di token. Per ulteriori informazioni sugli scenari federativi, vedere Federazione e token emessi. Tutte le credenziali client si trovano nella endpointBehaviors section, come mostrato nel codice seguente.

<behaviors>
 <endpointBehaviors>
  <behavior name="EndpointBehavior1">
   <clientCredentials>
    <clientCertificate findValue="cn=www.contoso.com"   
        storeLocation="LocalMachine"
        storeName="AuthRoot" x509FindType="FindBySubjectName" />
    <serviceCertificate>
     <defaultCertificate findValue="www.cohowinery.com" 
                    storeLocation="LocalMachine"
                    storeName="Root" x509FindType="FindByIssuerName" />
    <authentication revocationMode="Online"
                    trustedStoreLocation="LocalMachine" />
    </serviceCertificate>
   </clientCredentials>
  </behavior>
 </endpointBehaviors>

Elemento <clientCertifictate>

Questo elemento consente di impostare il certificato utilizzato per autenticare il client. Per ulteriori informazioni, vedere Procedura: specificare valori di credenziali client.

<httpDigest>

Questa funzionalità deve essere attivata con Active Directory in Windows e Internet Information Services (IIS). Per ulteriori informazioni, vedere https://go.microsoft.com/fwlink/?LinkId=88443.

Elemento <issuedToken>

L'<issuedToken> of <clientCredentials> element contiene gli elementi utilizzati per configurare un'autorità emittente locale di token oppure i comportamenti utilizzati in un servizio token di protezione. Per istruzioni su come configurare un client affinché utilizzi un'autorità emittente locale, vedere Procedura: configurare un emittente locale.

<localIssuerAddress>

Specifica l'indirizzo predefinito di un servizio token di protezione. Questo elemento viene utilizzato quando l'associazione WSFederationHttpBinding non fornisce alcun URL per il servizio token di protezione oppure quando l'indirizzo dell'autorità emittente di un'associazione federativa è https://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous o null. In questi casi le credenziali ClientCredentials devono essere configurate con l'indirizzo dell'autorità emittente locale e con l'associazione da utilizzare per comunicare con tale autorità emittente.

<issuerChannelBehaviors>

L'<issuerChannelBehaviors> Element consente di aggiungere i comportamenti client di WCF utilizzati per comunicare con un servizio token di protezione. I comportamenti client vengono definiti nella endpointBehaviors section. Per utilizzare un comportamento definito, aggiungere un elemento <add> all'elemento <issuerChannelBehaviors> con due attributi. Impostare l'indirizzo issuerAddress sull'URL del servizio token di protezione e quindi impostare l'attributo behaviorConfiguration sul nome del comportamento di endpoint definito, come mostrato nell'esempio seguente.

<clientCredentials>
   <issuedToken>
      <issuerChannelBehaviors>
         <add issuerAddress="https://www.contoso.com"
               behaviorConfiguration="clientBehavior1" />

Elemento <serviceCertificate>

Utilizzare questo elemento per controllare l'autenticazione dei certificati di servizio.

L'elemento <defaultCertificate> può contenere un solo certificato da utilizzare quando il servizio non specifica alcun certificato.

Utilizzare l'elemento <scopedCertificates> e l'<add> element for <scopedCertificates> per impostare i certificati di servizio associati a servizi specifici. L'elemento <add> contiene l'attributo targetUri utilizzato per associare il certificato al servizio.

L'elemento <authentication> specifica il livello di attendibilità utilizzato per autenticare i certificati. Per impostazione predefinita, il livello è impostato su "ChainTrust". Tale impostazione prevede che ogni certificato appartenga a una gerarchia di certificati che termina in un certificato attendibile situato all'inizio della catena. Si tratta della modalità più sicura. Il livello può inoltre essere impostato su "PeerOrChainTrust", a indicare che sia i certificati autocertificati (trust peer) sia i certificati appartenenti a una catena di trust sono ritenuti attendibili. Poiché i certificati autocertificati non devono essere acquistati da un'autorità attendibile, questo livello viene utilizzato in fase di sviluppo e di debug dei client e dei servizi. Quando si distribuisce un client è invece opportuno utilizzare il livello "ChainTrust". Il livello può inoltre essere impostato su "Custom" o "None". Quando si imposta il livello "Custom" è necessario impostare anche l'attributo CustomCertificateValidatorType sull'assembly e sul tipo utilizzati per convalidare il certificato. Per creare una convalida personalizzata è necessario ereditare una classe dalla classe astratta X509CertificateValidator. Per ulteriori informazioni, vedere Procedura: creare un servizio che utilizza una convalida del certificato personalizzata.

L'elemento <authentication> contiene un attributo RevocationMode che specifica la modalità per la revoca dei certificati. L'impostazione predefinita è "online", a indicare che i certificati vengono contrassegnati automaticamente per la revoca. Per ulteriori informazioni, vedere Utilizzo dei certificati.

ServiceAuthorization

L'elemento <serviceAuthorization> contiene elementi che influiscono su autorizzazioni, provider del ruolo personalizzati e rappresentazioni.

La classe PrincipalPermissionAttribute viene applicata a un metodo di servizio. Questo attributo specifica i gruppi di utenti da utilizzare quando si autorizza l'utilizzo di un metodo protetto. Il valore predefinito è "UseWindowsGroups" e specifica che la ricerca degli ID che tentano di accedere a una determinata risorsa viene eseguita nei gruppi di Windows, ad esempio "Administrators" o "Users". È inoltre possibile specificare "UseAspNetRoles" per utilizzare un provider del ruoli personalizzato configurato nell'elemento <system.web>, come mostrato nel codice seguente.

<system.web>
  <membership defaultProvider="SqlProvider" 
   userIsOnlineTimeWindow="15">
     <providers>
       <clear />
       <add 
          name="SqlProvider" 
          type="System.Web.Security.SqlMembershipProvider" 
          connectionStringName="SqlConn"
          applicationName="MembershipProvider"
          enablePasswordRetrieval="false"
          enablePasswordReset="false"
          requiresQuestionAndAnswer="false"
          requiresUniqueEmail="true"
          passwordFormat="Hashed" />
     </providers>
   </membership>
  <!-- Other configuration code not shown.-->
</system.web>

Nell'esempio di codice seguente viene illustrato l'utilizzo di un elemento roleProviderName con l'attributo principalPermissionMode.

<behaviors>
 <behavior name="ServiceBehaviour">        
  <serviceAuthorization principalPermissionMode ="UseAspNetRoles" 
                        roleProviderName ="SqlProvider" />
</behavior> 
   <!-- Other configuration code not shown. -->
</behaviors>

Configurazione dei controlli di protezione

Utilizzare l'serviceSecurityAudit element per specificare il log in cui scrivere e i tipi di evento da registrare. Per ulteriori informazioni, vedere Controllo degli eventi di protezione.

<system.serviceModel>
<serviceBehaviors>
  <behavior name="NewBehavior">
    <serviceSecurityAudit auditLogLocation="Application" 
             suppressAuditFailure="true"
             serviceAuthorizationAuditLevel="Success" 
             messageAuthenticationAuditLevel="Success" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Scambio protetto di metadati

L'esportazione e l'invio di metadati ai client risulta particolarmente utile per gli sviluppatori di servizi e client, in quanto consente il download di codice client e di configurazione. Per ridurre l'esposizione di un servizio agli utenti malintenzionati, questo trasferimento può essere protetto mediante il meccanismo HTTPS (ovvero SSL su HTTP). A tale scopo, è anzitutto necessario associare un certificato X.509 adatto a una porta specifica del computer che ospita il servizio. (Per ulteriori informazioni, vedere Utilizzo dei certificati.) Quindi, è necessario aggiungere un <serviceMetadata> Element nella configurazione del servizio e impostare l'attributo HttpsGetEnabled su true. Infine, come mostrato nell'esempio seguente, è necessario impostare l'attributo HttpsGetUrl sull'URL dell'endpoint di metadati del servizio.

<behaviors>
 <serviceBehaviors>
  <behavior name="NewBehavior">
    <serviceMetadata httpsGetEnabled="true" 
     httpsGetUrl="https://myComputerName/myEndpoint" />
  </behavior>
 </serviceBehaviors>
</behaviors>

Vedere anche

Concetti

Controllo degli eventi di protezione