Dela via

Säkerhetsbeteenden i WCF

  • Artikel

I Windows Communication Foundation (WCF) ändrar beteenden körningsbeteende på tjänstnivå eller slutpunktsnivå. (Mer information om beteenden i allmänhet finns iAnge körningsbeteende för tjänsten.) Säkerhetsbeteenden tillåter kontroll över autentiseringsuppgifter, autentisering, auktorisering och granskningsloggar. Du kan använda beteenden antingen genom programmering eller genom konfiguration.

Den här artikeln fokuserar på att konfigurera följande beteenden som rör säkerhetsfunktioner:

Ange autentiseringsuppgifter med beteenden

<Använd serviceCredentials> och <clientCredentials> för att ange autentiseringsvärden för en tjänst eller klient. Den underliggande bindningskonfigurationen avgör om en autentiseringsuppgift måste anges. Om säkerhetsläget till exempel är inställt på Noneautentiserar både klienter och tjänster inte varandra och kräver inga autentiseringsuppgifter av någon typ.

Å andra sidan kan tjänstbindningen kräva en typ av klientautentiseringsuppgifter. I så fall kan du behöva ange ett värde för autentiseringsuppgifter med hjälp av ett beteende. (Mer information om möjliga typer av autentiseringsuppgifter finns i Välja en typ av autentiseringsuppgifter.) I vissa fall, till exempel när Windows-autentiseringsuppgifter används för att autentisera, upprättar miljön automatiskt det faktiska autentiseringsvärdet och du behöver inte uttryckligen ange autentiseringsvärdet (såvida du inte vill ange en annan uppsättning autentiseringsuppgifter).

Alla autentiseringsuppgifter för tjänsten hittas som underordnade element i tjänstenBehaviors>.< I följande exempel visas ett certifikat som används som en tjänstautentiseringsuppgift.

<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>

Autentiseringsuppgifter för tjänsten

ServiceCredentials ><innehåller fyra underordnade element. Elementen och deras användning beskrivs i följande avsnitt.

<serviceCertificate-element>

Använd det här elementet för att ange ett X.509-certifikat som används för att autentisera tjänsten till klienter med hjälp av meddelandesäkerhetsläge. Om du använder ett certifikat som förnyas regelbundet ändras tumavtrycket. I så fall använder du ämnesnamnet som X509FindType eftersom certifikatet kan utfärdas på nytt med samma ämnesnamn.

Mer information om hur du använder elementet finns i Så här anger du värden för klientautentiseringsuppgifter.

<certifikat för> <clientCertificate-element>

<Använd certifikatelementet> när tjänsten måste ha klientens certifikat i förväg för att kommunicera säkert med klienten. Detta inträffar när du använder duplex-kommunikationsmönstret. I det mer typiska mönstret för begäran-svar innehåller klienten sitt certifikat i begäran, som tjänsten använder för att skydda sitt svar tillbaka till klienten. Duplex-kommunikationsmönstret har dock inga begäranden och svar. Tjänsten kan inte härleda klientens certifikat från kommunikationen och därför kräver tjänsten klientens certifikat i förväg för att skydda meddelandena till klienten. Du måste hämta klientens certifikat på ett out-of-band-sätt och ange certifikatet med det här elementet. Mer information om duplex-tjänster finns i Så här skapar du ett Duplex-kontrakt.

<autentisering> av <clientCertificate-element>

Med <autentiseringselementet> kan du anpassa hur klienter autentiseras. Du kan ange CertificateValidationMode attributet till None, ChainTrust, PeerOrChainTrust, PeerTrusteller Custom. Som standard är nivån inställd ChainTrustpå , som anger att varje certifikat måste hittas i en hierarki med certifikat som slutar på en rotutfärdare överst i kedjan. Det här är det säkraste läget. Du kan också ange värdet till PeerOrChainTrust, som anger att självutfärdade certifikat (peer-förtroende) godkänns samt certifikat som finns i en betrodd kedja. Det här värdet används vid utveckling och felsökning av klienter och tjänster eftersom självutfärdade certifikat inte behöver köpas från en betrodd utfärdare. När du distribuerar en klient använder du ChainTrust värdet i stället. Du kan också ange värdet till Custom. När värdet anges Custom måste du också ange CustomCertificateValidatorType attributet till en sammansättning och typ som används för att verifiera certifikatet. Om du vill skapa en egen anpassad validator måste du ärva från den abstrakta X509CertificateValidator klassen.

<issuedTokenAuthentication-element>

Det utfärdade tokenscenariot har tre steg. I den första fasen refereras en klient som försöker komma åt en tjänst till en säker tokentjänst (STS). STS autentiserar sedan klienten och utfärdar därefter klienten en token, vanligtvis en SAML-token (Security Assertions Markup Language). Klienten återgår sedan till tjänsten med token. Tjänsten undersöker token för data som gör att tjänsten kan autentisera token och därmed klienten. Om du vill autentisera token måste certifikatet som tjänsten för säker token använder vara känt för tjänsten. Elementet <issuedTokenAuthentication> är lagringsplatsen för sådana certifikat för säker tokentjänst. Om du vill lägga till certifikat använder du knownCertificates>.< Infoga ett <tillägg> för varje certifikat, enligt följande exempel.

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

Som standard måste certifikaten hämtas från en säker tokentjänst. Dessa "kända" certifikat säkerställer att endast legitima klienter kan komma åt en tjänst.

Du bör använda samlingen <allowedAudienceUris> i ett federerat program som använder en säker tokentjänst (STS) som utfärdar SamlSecurityToken säkerhetstoken. När STS utfärdar säkerhetstoken kan den ange URI för de webbtjänster som säkerhetstoken är avsedd för genom att lägga till en SamlAudienceRestrictionCondition i säkerhetstoken. Det gör att mottagarens webbtjänst kan SamlSecurityTokenAuthenticator verifiera att den utfärdade säkerhetstoken är avsedd för den här webbtjänsten genom att ange att den här kontrollen ska ske genom att göra följande:

  • audienceUriMode Ange attributet< issuedTokenAuthentication> till Always eller BearerKeyOnly.

  • Ange uppsättningen med giltiga URI:er genom att lägga till URI:erna i den här samlingen. Det gör du genom att infoga ett <tillägg> för varje URI

Mer information finns i SamlSecurityTokenAuthenticator.

Mer information om hur du använder det här konfigurationselementet finns i Så här konfigurerar du autentiseringsuppgifter för en federationstjänst.

Tillåt anonyma CardSpace-användare

AllowUntrustedRsaIssuers Om attributet för elementet <IssuedTokenAuthentication> anges till true explicit kan alla klienter presentera en självutfärdad token signerad med ett godtyckligt RSA-nyckelpar. Utfärdaren är inte betrodd eftersom nyckeln inte har några associerade utfärdardata. En CardSpace-användare kan skapa ett själv utfärdat kort som innehåller självbetjäningsanspråk för identitet. Använd den här funktionen med försiktighet. Om du vill använda den här funktionen bör du se den offentliga RSA-nyckeln som ett säkrare lösenord som ska lagras i en databas tillsammans med ett användarnamn. Innan du tillåter en klientåtkomst till tjänsten kontrollerar du den klientdelade offentliga RSA-nyckeln genom att jämföra den med den lagrade offentliga nyckeln för det presenterade användarnamnet. Detta förutsätter att du har upprättat en registreringsprocess där användare kan registrera sina användarnamn och associera dem med de självutfärdade offentliga RSA-nycklarna.

Klientautentiseringsuppgifter

Klientautentiseringsuppgifter används för att autentisera klienten till tjänster i de fall där ömsesidig autentisering krävs. Du kan använda avsnittet för att ange tjänstcertifikat för scenarier där klienten måste skydda meddelanden till en tjänst med tjänstens certifikat.

Du kan också konfigurera en klient som en del av ett federationsscenario för att använda utfärdade token från en säker tokentjänst eller en lokal utfärdare av token. Mer information om federerade scenarier finns i Federation och Utfärdade token. Alla klientautentiseringsuppgifter finns under <endpointBehaviors>, som du ser i följande kod.

<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>

<clientCertificate-element>

Ange det certifikat som används för att autentisera klienten med det här elementet. Mer information finns i Så här anger du värden för klientautentiseringsuppgifter.

<httpDigest>

Den här funktionen måste vara aktiverad med Active Directory i Windows och Internet Information Services (IIS). Mer information finns i Sammanfattad autentisering i IIS 6.0.

<issuedToken-element>

issuedToken <> innehåller de element som används för att konfigurera en lokal utfärdare av token eller beteenden som används med en säkerhetstokentjänst. Anvisningar om hur du konfigurerar en klient för att använda en lokal utfärdare finns i Så här konfigurerar du en lokal utfärdare.

<localIssuerAddress>

Anger en standardadress för säkerhetstokentjänsten. Detta används när WSFederationHttpBinding inte anger en URL för säkerhetstokentjänsten, eller när utfärdaradressen för en federerad bindning är http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous eller null. I sådana fall ClientCredentials måste konfigureras med adressen till den lokala utfärdaren och bindningen som ska användas för att kommunicera med utfärdaren.

<issuerChannelBehaviors>

<Använd issuerChannelBehaviors> för att lägga till WCF-klientbeteenden som används vid kommunikation med en säkerhetstokentjänst. Definiera klientbeteenden i avsnittet <endpointBehaviors> . Om du vill använda ett definierat beteende lägger du till ett <add> element i elementet <issuerChannelBehaviors> med två attribut. issuerAddress Ange till URL:en för tjänsten för säkerhetstoken och ange behaviorConfiguration attributet till namnet på det definierade slutpunktsbeteendet, som du ser i följande exempel.

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

<serviceCertificate-element>

Använd det här elementet för att styra autentiseringen av tjänstcertifikat.

Elementet <defaultCertificate> kan lagra ett enda certifikat som används när tjänsten inte anger något certifikat.

<Använd scopedCertificates> och <lägg till> för att ange tjänstcertifikat som är associerade med specifika tjänster. Elementet <add> innehåller ett targetUri attribut som används för att associera certifikatet med tjänsten.

<Autentiseringselementet> anger den förtroendenivå som används för att autentisera certifikat. Som standard är nivån inställd på "ChainTrust", som anger att varje certifikat måste hittas i en hierarki med certifikat som slutar på en betrodd certifikatutfärdare överst i kedjan. Det här är det säkraste läget. Du kan också ange värdet till "PeerOrChainTrust", som anger att självutfärdade certifikat (peer-förtroende) godkänns samt certifikat som finns i en betrodd kedja. Det här värdet används vid utveckling och felsökning av klienter och tjänster eftersom självutfärdade certifikat inte behöver köpas från en betrodd utfärdare. När du distribuerar en klient använder du värdet "ChainTrust" i stället. Du kan också ange värdet "Anpassad" eller "Ingen". Om du vill använda värdet "Anpassad" måste du också ange CustomCertificateValidatorType attributet till en sammansättning och typ som används för att verifiera certifikatet. Om du vill skapa en egen anpassad validator måste du ärva från den abstrakta X509CertificateValidator klassen. Mer information finns i Så här skapar du en tjänst som använder en anpassad certifikatverifierare.

<Autentiseringselementet> innehåller ett RevocationMode attribut som anger hur certifikat kontrolleras för återkallning. Standardvärdet är "online", vilket anger att certifikat automatiskt kontrolleras för återkallande. Mer information finns i Arbeta med certifikat.

ServiceAuthorization

ServiceAuthorization-elementet ><innehåller element som påverkar auktorisering, anpassade rollprovidrar och personifiering.

Klassen PrincipalPermissionAttribute tillämpas på en tjänstmetod. Attributet anger vilka grupper av användare som ska användas vid auktorisering av användning av en skyddad metod. Standardvärdet är "UseWindowsGroups" och anger att Windows-grupper, till exempel "Administratörer" eller "Användare", genomsöks efter en identitet som försöker komma åt en resurs. Du kan också ange "UseAspNetRoles" för att använda en anpassad rollprovider som är konfigurerad under elementet <system.web> , enligt följande kod.

<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>

Följande kod visar den roleProviderName som används med attributet principalPermissionMode .

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

Konfigurera säkerhetsgranskningar

<Använd serviceSecurityAudit> för att ange loggen som skrivits till och vilka typer av händelser som ska loggas. Mer information finns i Granskning.

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

Säker metadatautbyte

Att exportera metadata till klienter är praktiskt för tjänst- och klientutvecklare, eftersom det möjliggör nedladdning av konfiguration och klientkod. För att minska exponeringen av en tjänst för skadliga användare är det möjligt att skydda överföringen med hjälp av mekanismen SSL via HTTP (HTTPS). För att göra det måste du först binda ett lämpligt X.509-certifikat till en specifik port på den dator som är värd för tjänsten. (Mer information finns i Arbeta med certifikat.) För det andra lägger du till en serviceMetadata> i tjänstkonfigurationen och anger HttpsGetEnabled attributet till true.< HttpsGetUrl Ange slutligen attributet till URL:en för tjänstmetadataslutpunkten, som du ser i följande exempel.

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

Se även