Důvěryhodná služba facade

Článek
03/05/2024

Ukázka TrustedFacade ukazuje, jak tok informací o identitě volajícího z jedné služby do druhé pomocí infrastruktury zabezpečení WCF (Windows Communication Foundation).

Jedná se o běžný způsob návrhu, jak zpřístupnit funkce poskytované službou veřejné síti pomocí fasádní služby. Služba fasády se obvykle nachází v hraniční síti (označované také jako DMZ, demilitarizovaná zóna a monitorovaná podsíť) a komunikuje s back-endovou službou, která implementuje obchodní logiku a má přístup k interním datům. Komunikační kanál mezi fasádní službou a back-endovou službou prochází bránou firewall a obvykle je omezený pouze pro jeden účel.

Tato ukázka se skládá z následujících součástí:

Klient kalkulačky
Služba fasády kalkulačky
Back-endová služba kalkulačky

Za ověření žádosti a ověření volajícího zodpovídá služba fasády. Po úspěšném ověření a ověření předá požadavek back-endové službě pomocí řízeného komunikačního kanálu z hraniční sítě do interní sítě. Součástí předávané žádosti je, že služba fasády obsahuje informace o identitě volajícího, aby back-endová služba mohly tyto informace použít při zpracování. Identita volajícího se přenáší pomocí tokenu Username zabezpečení uvnitř hlavičky zprávy Security . Ukázka používá infrastrukturu zabezpečení WCF k přenosu a extrahování těchto informací z hlavičky Security .

Důležité

Back-endová služba důvěřuje službě fasády za účelem ověření volajícího. Z tohoto důvodu back-endová služba znovu neověřuje volajícího; používá informace o identitě poskytované službou fasády v předávané žádosti. Kvůli tomuto vztahu důvěryhodnosti musí back-endová služba ověřit fasádní službu, aby se zajistilo, že předávaná zpráva pochází z důvěryhodného zdroje – v tomto případě služba fasády.

Implementace

V této ukázce jsou dvě komunikační cesty. První je mezi klientem a službou fasády, druhá je mezi fasádní službou a back-endovou službou.

Komunikační cesta mezi klientem a službou Façade Service

Klient na komunikační cestu ke službě fasády používá wsHttpBinding s typem UserName přihlašovacích údajů klienta. To znamená, že klient používá k ověření ve službě fasády uživatelské jméno a heslo a služba fasády používá k ověření klienta certifikát X.509. Konfigurace vazby vypadá jako v následujícím příkladu.

<bindings>
  <wsHttpBinding>
    <binding name="Binding1">
      <security mode="Message">
        <message clientCredentialType="UserName"/>
      </security>
    </binding>
  </wsHttpBinding>
</bindings>

Služba fasády ověřuje volajícího pomocí vlastní UserNamePasswordValidator implementace. Pro demonstrační účely ověřování zajišťuje, aby uživatelské jméno volajícího odpovídalo zadanému heslu. V reálné situaci se uživatel pravděpodobně ověřuje pomocí služby Active Directory nebo vlastního poskytovatele členství ASP.NET. Implementace validátoru se nachází v FacadeService.cs souboru.

public class MyUserNamePasswordValidator : UserNamePasswordValidator
{
    public override void Validate(string userName, string password)
    {
        // check that username matches password
        if (null == userName || userName != password)
        {
            Console.WriteLine("Invalid username or password");
            throw new SecurityTokenValidationException(
                       "Invalid username or password");
        }
    }
}

Vlastní validátor je nakonfigurovaný tak, aby se používal uvnitř serviceCredentials chování v konfiguračním souboru fasády služby. Toto chování se také používá ke konfiguraci certifikátu X.509 služby.

<behaviors>
  <serviceBehaviors>
    <behavior name="FacadeServiceBehavior">
      <!--The serviceCredentials behavior allows you to define -->
      <!--a service certificate. -->
      <!--A service certificate is used by the service to  -->
      <!--authenticate itself to its clients and to provide  -->
      <!--message protection. -->
      <!--This configuration references the "localhost"  -->
      <!--certificate installed during the setup instructions. -->
      <serviceCredentials>
        <serviceCertificate
               findValue="localhost"
               storeLocation="LocalMachine"
               storeName="My"
               x509FindType="FindBySubjectName" />
        <userNameAuthentication userNamePasswordValidationMode="Custom"
            customUserNamePasswordValidatorType=
           "Microsoft.ServiceModel.Samples.MyUserNamePasswordValidator,
            FacadeService"/>
      </serviceCredentials>
    </behavior>
  </serviceBehaviors>
</behaviors>

Komunikační cesta mezi službou façade Service a back-endovou službou

Komunikační cesta back-endové služby používá customBinding fasádní službu, která se skládá z několika vazebních prvků. Tato vazba provádí dvě věci. Ověřuje fasádní službu a back-endovou službu, aby se zajistilo, že komunikace je zabezpečená a pochází z důvěryhodného zdroje. Kromě toho také přenáší počáteční identitu volajícího uvnitř tokenu Username zabezpečení. V takovém případě se do back-endové služby přenese pouze počáteční uživatelské jméno volajícího, heslo není součástí zprávy. Důvodem je to, že back-endová služba důvěřuje službě fasády k ověření volajícího před předáním požadavku na ni. Vzhledem k tomu, že se fasáda ověřuje vůči back-endové službě, může back-endová služba důvěřovat informacím obsaženým v předávané žádosti.

Následuje konfigurace vazby pro tuto komunikační cestu.

<bindings>
  <customBinding>
    <binding name="ClientBinding">
      <security authenticationMode="UserNameOverTransport"/>
      <windowsStreamSecurity/>
      <tcpTransport/>
    </binding>
  </customBinding>
</bindings>

Prvek <vazby zabezpečení> se postará o přenos a extrakci uživatelského jména počátečního volajícího. WindowsStreamSecurity ><a< tcpTransport> se stará o ověřování fasád a back-endových služeb a ochrany zpráv.

Aby bylo možné požadavek přeposlat, musí implementace služby fasády poskytnout uživatelské jméno počátečního volajícího, aby ji infrastruktura zabezpečení WCF mohla umístit do přeposlané zprávy. Počáteční uživatelské jméno volajícího je poskytováno v implementaci služby fasády tím, že ho nastavíte ve ClientCredentials vlastnosti instance proxy klienta, kterou služba fasády používá ke komunikaci s back-endovou službou.

Následující kód ukazuje, jak GetCallerIdentity se metoda implementuje ve službě fasády. Jiné metody používají stejný vzor.

public string GetCallerIdentity()
{
    CalculatorClient client = new CalculatorClient();
    client.ClientCredentials.UserName.UserName = ServiceSecurityContext.Current.PrimaryIdentity.Name;
    string result = client.GetCallerIdentity();
    client.Close();
    return result;
}

Jak je znázorněno v předchozím kódu, heslo není nastaveno na ClientCredentials vlastnost, je nastaveno pouze uživatelské jméno. Infrastruktura zabezpečení WCF vytvoří token zabezpečení uživatelského jména bez hesla v tomto případě, což je přesně to, co je v tomto scénáři potřeba.

V back-endové službě musí být ověřeny informace obsažené v tokenu zabezpečení uživatelského jména. Ve výchozím nastavení se zabezpečení WCF pokusí namapovat uživatele na účet Systému Windows pomocí zadaného hesla. V tomto případě není k dispozici žádné heslo a back-endová služba není nutná k ověření uživatelského jména, protože ověřování již provedla služba fasády. Pokud chcete tuto funkci implementovat ve WCF, vlastní je poskytována, která vynucuje pouze to, UserNamePasswordValidator že uživatelské jméno je zadáno v tokenu a neprovádí žádné další ověřování.

public class MyUserNamePasswordValidator : UserNamePasswordValidator
{
    public override void Validate(string userName, string password)
    {
        // Ignore the password because it is empty,
        // we trust the facade service to authenticate the client.
        // Accept the username information here so that the
        // application gets access to it.
        if (null == userName)
        {
            Console.WriteLine("Invalid username");
            throw new
             SecurityTokenValidationException("Invalid username");
        }
    }
}

Vlastní validátor je nakonfigurovaný tak, aby se používal uvnitř serviceCredentials chování v konfiguračním souboru fasády služby.

<behaviors>
  <serviceBehaviors>
    <behavior name="BackendServiceBehavior">
      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom"
           customUserNamePasswordValidatorType=
          "Microsoft.ServiceModel.Samples.MyUserNamePasswordValidator,
           BackendService"/>
      </serviceCredentials>
    </behavior>
  </serviceBehaviors>
</behaviors>

K extrakci informací o uživatelském jménu a informace o důvěryhodném účtu služby façade používá ServiceSecurityContext implementace back-endové služby třídu. Následující kód ukazuje, jak GetCallerIdentity je metoda implementována.

public string GetCallerIdentity()
{
    // Facade service is authenticated using Windows authentication.
    //Its identity is accessible.
    // On ServiceSecurityContext.Current.WindowsIdentity.
    string facadeServiceIdentityName =
          ServiceSecurityContext.Current.WindowsIdentity.Name;

    // The client name is transmitted using Username authentication on
    //the message level without the password
    // using a supporting encrypted UserNameToken.
    // Claims extracted from this supporting token are available in
    // ServiceSecurityContext.Current.AuthorizationContext.ClaimSets
    // collection.
    string clientName = null;
    foreach (ClaimSet claimSet in
        ServiceSecurityContext.Current.AuthorizationContext.ClaimSets)
    {
        foreach (Claim claim in claimSet)
        {
            if (claim.ClaimType == ClaimTypes.Name &&
                                   claim.Right == Rights.Identity)
            {
                clientName = (string)claim.Resource;
                break;
            }
        }
    }
    if (clientName == null)
    {
        // In case there was no UserNameToken attached to the request.
        // In the real world implementation the service should reject
        // this request.
        return "Anonymous caller via " + facadeServiceIdentityName;
    }

    return clientName + " via " + facadeServiceIdentityName;
}

Informace o účtu služby fasády se extrahují pomocí ServiceSecurityContext.Current.WindowsIdentity vlastnosti. Pro přístup k informacím o počátečním volajícím používá ServiceSecurityContext.Current.AuthorizationContext.ClaimSets back-endová služba vlastnost. Identity Hledá deklaraci identity s typem Name. Tato deklarace identity je automaticky generována infrastrukturou zabezpečení WCF z informací obsažených v tokenu Username zabezpečení.

Spuštění ukázky

Při spuštění ukázky se požadavky na operace a odpovědi zobrazí v okně konzoly klienta. Stisknutím klávesy ENTER v okně klienta klienta ukončete klienta. Služby můžete vypnout stisknutím klávesy ENTER v oknech konzoly back-endové služby.

Username authentication required.
Provide a valid machine or domain ac
   Enter username:
user
   Enter password:
****
user via MyMachine\testaccount
Add(100,15.99) = 115.99
Subtract(145,76.54) = 68.46
Multiply(9,81.25) = 731.25
Divide(22,7) = 3.14285714285714

Press <ENTER> to terminate client.

Dávkový soubor Setup.bat, který je součástí ukázky scénáře Důvěryhodného fasády, umožňuje nakonfigurovat server s příslušným certifikátem pro spuštění fasádní služby, která vyžaduje zabezpečení založené na certifikátech k ověření vůči klientovi. Podrobnosti najdete v postupu nastavení na konci tohoto tématu.

Níže najdete stručný přehled různých částí dávkových souborů.

Vytvoření certifikátu serveru

Následující řádky z dávkového souboru Setup.bat vytvoří certifikát serveru, který se má použít.
```
echo ************
echo Server cert setup starting
echo %SERVER_NAME%
echo ************
echo making server cert
echo ************
makecert.exe -sr LocalMachine -ss MY -a sha1 -n CN=%SERVER_NAME% -sky exchange -pe
```
Proměnná %SERVER_NAME% určuje název serveru – výchozí hodnota je localhost. Certifikát je uložen v úložišti LocalMachine.
Instalace certifikátu façade služby do důvěryhodného úložiště certifikátů klienta.

Následující řádek zkopíruje certifikát façade služby do klientského úložiště důvěryhodných osob. Tento krok je povinný, protože certifikáty generované Makecert.exe nejsou implicitně důvěryhodné klientským systémem. Pokud už máte certifikát, který je kořenový v kořenovém certifikátu klienta ( například certifikát vydaný Microsoftem), tento krok naplnění úložiště klientských certifikátů certifikátem pomocí certifikátu serveru se nevyžaduje.
```
certmgr.exe -add -r LocalMachine -s My -c -n %SERVER_NAME% -r CurrentUser -s TrustedPeople
```

Nastavení, sestavení a spuštění ukázky

Ujistěte se, že jste pro ukázky windows Communication Foundation provedli jednorázovou instalační proceduru.
Pokud chcete sestavit edici C# nebo Visual Basic .NET řešení, postupujte podle pokynů v části Sestavení ukázek windows Communication Foundation.

Spuštění ukázky na stejném počítači

Ujistěte se, že cesta obsahuje složku, ve které se nachází Makecert.exe.
Spusťte Setup.bat z ukázkové instalační složky. Tím se nainstalují všechny certifikáty potřebné pro spuštění ukázky.
V samostatném okně konzoly spusťte BackendService.exe z adresáře \BackendService\bin.
V samostatném okně konzoly spusťte FacadeService.exe z adresáře \DiagnosticsService\bin.
Spusťte Client.exe z \client\bin. Aktivita klienta se zobrazí v aplikaci konzoly klienta.
Pokud klient a služba nemůžou komunikovat, přečtěte si téma Řešení potíží Tipy pro ukázky WCF.

Vyčištění po ukázce

Po dokončení spuštění ukázky spusťte Cleanup.bat ve složce s ukázkami.

Sdílet prostřednictvím