Condividi tramite

Comportamenti di sicurezza in WCF

  • Articolo

In Windows Communication Foundation (WCF), i comportamenti modificano il comportamento di runtime a livello di servizio o a livello di endpoint. Per altre informazioni sui comportamenti in generale, vedere Specifica del comportamento di runtime del servizio. I comportamenti di sicurezza 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 articolo, viene descritto come configurare i comportamenti relativi alle funzioni di sicurezza elencati di seguito:

Impostare le credenziali tramite i comportamenti

Usare <serviceCredentials> e <clientCredentials> per impostare i valori delle credenziali per un servizio o un client. La configurazione dell'associazione sottostante determina se occorre impostare una credenziale. Ad esempio, se la modalità di sicurezza è 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 altre informazioni sui possibili tipi 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 è necessario eseguire l'impostazione manuale dei valori delle credenziali.

Tutte le credenziali di servizio si trovano in <serviceBehaviors> 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

<serviceCredentials> 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 sicurezza Messaggio. L'identificazione digitale di un certificato rinnovato periodicamente viene aggiornata di conseguenza. In questo caso, poiché il certificato può essere rilasciato nuovamente con lo stesso nome del soggetto, usare quest'ultimo come tipo X509FindType.

Per altre informazioni sull'uso dell'elemento, vedere Procedura: Specificare i valori delle 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 usa il modello di comunicazione duplex. Nel modello più comune di comunicazione richiesta-risposta, il client include il proprio certificato nella richiesta e il servizio usa 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 proteggere i messaggi inviati al client, il servizio deve disporre in anticipo del certificato del client. Il certificato del client deve essere ottenuto fuori banda e deve essere specificato tramite questo elemento. Per altre 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ù protetta. 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 usato in fase di sviluppo e di debug dei client e dei servizi. Quando si distribuisce un client è invece opportuno usare 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 usati per convalidare il certificato. Per creare un validator personalizzato è 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 sicurezza (STS). Nella seconda fase, il servizio token di sicurezza 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 usare 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 sicurezza. L'elemento <issuedTokenAuthentication> rappresenta il repository dei certificati usati dal servizio token di sicurezza. Per aggiungere certificati, usare <knownCertificates>. Inserire un <add> 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 sicurezza. Questi certificati "riconosciuti" garantiscono che solo i client autorizzati siano in grado di accedere a un determinato servizio.

È necessario utilizzare la raccolta <allowedAudienceUris> in un'applicazione federata che utilizza un servizio token di sicurezza (STS) che emette token di sicurezza SamlSecurityToken. Quando emette il token di sicurezza, il servizio STS può specificare l'URI dei servizi Web per cui si desidera usare il token di sicurezza tramite l'aggiunta di una condizione SamlAudienceRestrictionCondition al token di sicurezza. Ciò consente all'autenticatore SamlSecurityTokenAuthenticator del servizio Web di destinazione di verificare che il token di sicurezza emesso sia associato a questo servizio Web specificando che questo controllo deve essere svolto mediante l'esecuzione delle operazioni seguenti:

  • Impostare l'attributo audienceUriMode di < issuedTokenAuthentication> su Always o BearerKeyOnly.

  • Specificare il set di URI validi, aggiungendo gli URI a questa raccolta. A tale scopo, inserire un <add> per ogni URI

Per ulteriori informazioni, vedere SamlSecurityTokenAuthenticator.

Per altre informazioni sull'uso di questo elemento di configurazione, vedere Procedura: Configurare le credenziali in un servizio federativo.

Autenticare gli 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 sicurezza 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 usate 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 federato in modo che utilizzi i token emessi da un servizio token di sicurezza o da un'autorità emittente locale di token. Per altre informazioni sugli scenari federati, vedere Federazione e token emessi. Tutte le credenziali client si trovano in <endpointBehaviors>, 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>
</behaviors>

Elemento <clientCertificate>

Questo elemento consente di impostare il certificato utilizzato per autenticare il client. Per altre informazioni, vedere Procedura: Specificare i valori delle credenziali client.

<httpDigest>

Questa funzionalità deve essere abilitata con Active Directory in Windows e Internet Information Services (IIS). Per altre informazioni, vedere Autenticazione digest in IIS 6.0.

Elemento <issuedToken>

<issuedToken> contiene gli elementi usati per configurare un'autorità emittente locale di token oppure i comportamenti usati in un servizio token di sicurezza. Per istruzioni sulla configurazione di un client per l'uso di un'autorità emittente locale, vedere Procedura: Configurare un'autorità di certificazione locale.

<localIssuerAddress>

Specifica l'indirizzo predefinito di un servizio token di sicurezza. Viene usato quando l'oggetto WSFederationHttpBinding non fornisce un URL per il servizio token di sicurezza o quando l'indirizzo dell'autorità emittente di un'associazione federata è http://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>

Usare <issuerChannelBehaviors> per aggiungere comportamenti client WCF usati durante la comunicazione con un servizio token di sicurezza. Definire i comportamenti del client nella sezione <endpointBehaviors>. 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 sicurezza, quindi impostare l'attributo behaviorConfiguration sul nome del comportamento di endpoint definito, come mostrato nell'esempio seguente.

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

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.

Usare <scopedCertificates> e <add> per impostare i certificati del 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'autorità di certificazione attendibile situata all'inizio della catena. Si tratta della modalità più protetta. Il livello può inoltre essere impostato su "PeerOrChainTrust" per indicare che sia i certificati autocertificati (trust peer) che quelli appartenenti a una catena di trust sono ritenuti attendibili. Poiché i certificati autocertificati non devono essere acquistati da un'autorità attendibile, questo livello viene usato 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 un validator personalizzato è necessario ereditare una classe dalla classe astratta X509CertificateValidator. Per altre informazioni, vedere Procedura: Creare un servizio che usa un validator del certificato personalizzato.

L'elemento <authentication> contiene un attributo RevocationMode che specifica la modalità per la revoca dei certificati. L'impostazione predefinita è "online" e indica che i certificati vengono contrassegnati automaticamente per la revoca. Per altre 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. L'attributo specifica i gruppi di utenti da usare quando si autorizza l'uso 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 illustrato 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'uso di un elemento roleProviderName con l'attributo principalPermissionMode.

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

Configurare i controlli di sicurezza

Utilizzare <serviceSecurityAudit> per specificare il log in cui scrivere e i tipi di evento da registrare. Per ulteriori informazioni, vedere Controllo.

<behaviors>
 <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 altre informazioni, vedere Utilizzo dei certificati. Quindi, è necessario aggiungere un <serviceMetadata> alla configurazione del servizio e impostare l'attributo HttpsGetEnabled su true. Impostare infine l'attributo HttpsGetUrl sull'URL dell'endpoint dei metadati del servizio, come illustrato nell'esempio seguente.

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

Vedi anche