Udostępnij za pośrednictwem

Nieobsługiwane scenariusze

  • Artykuł

Z różnych powodów program Windows Communication Foundation (WCF) nie obsługuje niektórych określonych scenariuszy zabezpieczeń. Na przykład system Windows XP Home Edition nie implementuje protokołów uwierzytelniania SSPI ani Kerberos, dlatego program WCF nie obsługuje uruchamiania usługi z uwierzytelnianiem systemu Windows na tej platformie. Inne mechanizmy uwierzytelniania, takie jak nazwa użytkownika/hasło i zintegrowane uwierzytelnianie HTTP/HTTPS, są obsługiwane podczas uruchamiania programu WCF w systemie Windows XP Home Edition.

Scenariusze personifikacji

Tożsamość personifikowana może nie przepływać, gdy klienci tworzą wywołania asynchroniczne

Gdy klient programu WCF wykonuje wywołania asynchroniczne do usługi WCF przy użyciu uwierzytelniania systemu Windows w ramach personifikacji, uwierzytelnianie może wystąpić z tożsamością procesu klienta zamiast personifikowanej tożsamości.

Program WCF nie obsługuje personifikacji i InvalidOperationException jest zgłaszany, gdy istnieją następujące warunki:

  • System operacyjny to Windows XP.

  • Tryb uwierzytelniania powoduje wyświetlenie tożsamości systemu Windows.

  • Właściwość Impersonation właściwości OperationBehaviorAttribute jest ustawiona na Required.

  • Tworzony jest token kontekstu zabezpieczeń oparty na stanie (SCT) (domyślnie tworzenie jest wyłączone).

SCT oparty na stanie można utworzyć tylko przy użyciu powiązania niestandardowego. Aby uzyskać więcej informacji, zobacz How to: Create a Security Context Token for a Secure Session (Jak utworzyć token kontekstu zabezpieczeń dla bezpiecznej sesji). W kodzie token jest włączony przez utworzenie elementu powiązania zabezpieczeń ( SymmetricSecurityBindingElement lub AsymmetricSecurityBindingElement) przy użyciu SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) metody lub SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) i ustawienie parametru requireCancellation na false. Parametr odnosi się do buforowania SCT. Ustawienie wartości w celu false włączenia funkcji SCT opartej na stanie.

Alternatywnie w konfiguracji token jest włączony przez utworzenie <>customBindingelementu , a następnie dodaniesecurity<> elementu i ustawienie atrybutu authenticationMode na SecureConversation i requireSecurityContextCancellation atrybut na .true

Uwaga

Powyższe wymagania są specyficzne. Na przykład CreateKerberosBindingElement element tworzy element powiązania, który powoduje tożsamość systemu Windows, ale nie ustanawia protokołu SCT. W związku z tym można go użyć z opcją Required w systemie Windows XP.

Możliwy konflikt ASP.NET

WCF i ASP.NET mogą włączać lub wyłączać personifikację. Gdy ASP.NET hostuje aplikację WCF, może istnieć konflikt między programem WCF a ustawieniami konfiguracji ASP.NET. W przypadku konfliktu ustawienie WCF ma pierwszeństwo, chyba że Impersonation właściwość jest ustawiona na NotAllowed, w tym przypadku ustawienie personifikacji ASP.NET ma pierwszeństwo.

Ładowanie zestawów może zakończyć się niepowodzeniem pod personifikacją

Jeśli personifikowany kontekst nie ma uprawnień dostępu do ładowania zestawu i jeśli jest to pierwszy raz, gdy środowisko uruchomieniowe języka wspólnego (CLR) próbuje załadować zestaw dla tej domeny AppDomain, AppDomain buforuje błąd. Kolejne próby załadowania tego zestawu (lub zestawów) kończą się niepowodzeniem, nawet po wycofaniu personifikacji, a nawet jeśli przywrócony kontekst ma prawa dostępu do załadowania zestawu. Wynika to z faktu, że clR nie ponownie załadować po zmianie kontekstu użytkownika. Aby odzyskać odzyskiwanie po awarii, należy ponownie uruchomić domenę aplikacji.

Uwaga

Wartość domyślna AllowedImpersonationLevel właściwości WindowsClientCredential klasy to Identification. W większości przypadków kontekst personifikacji na poziomie identyfikacji nie ma uprawnień do ładowania żadnych dodatkowych zestawów. Jest to wartość domyślna, dlatego jest to bardzo typowy warunek, o jakim należy pamiętać. Personifikacja na poziomie identyfikacji występuje również wtedy, gdy proces personifikacji nie ma SeImpersonate uprawnień. Aby uzyskać więcej informacji, zobacz Delegowanie i personifikacja.

Delegowanie wymaga negocjacji poświadczeń

Aby używać protokołu uwierzytelniania Kerberos z delegowaniem, należy zaimplementować protokół Kerberos z negocjowaniem poświadczeń (czasami nazywanym wieloetapowym lub wieloetapowym Kerberos). W przypadku zaimplementowania uwierzytelniania Kerberos bez negocjacji poświadczeń (czasami nazywanego jednorazowym lub jednonogowym Kerberos) zgłaszany jest wyjątek. Aby uzyskać więcej informacji na temat implementowania negocjacji poświadczeń, zobacz Debugowanie błędów uwierzytelniania systemu Windows.

Kryptografia

Algorytm SHA-256 jest obsługiwany tylko w przypadku użycia kluczy symetrycznych

Program WCF obsługuje różne algorytmy tworzenia szyfrowania i skrótu podpisu, które można określić przy użyciu zestawu algorytmów w powiązaniach dostarczanych przez system. W celu zwiększenia bezpieczeństwa usługa WCF obsługuje algorytmy Secure Hash Algorithm (SHA) 2, w szczególności SHA-256, do tworzenia skrótów skrótów podpisów. Ta wersja obsługuje algorytm SHA-256 tylko w przypadku użycia kluczy symetrycznych, takich jak klucze Protokołu Kerberos i gdzie certyfikat X.509 nie jest używany do podpisywania komunikatu. Program WCF nie obsługuje podpisów RSA (używanych w certyfikatach X.509) przy użyciu skrótu SHA-256 ze względu na bieżący brak obsługi RSA-SHA256 w systemie WinFX.

Skróty SHA-256 zgodne ze standardem FIPS nie są obsługiwane

Funkcja WCF nie obsługuje skrótów zgodnych ze standardem FIPS SHA-256, dlatego zestawy algorytmów używające algorytmu SHA-256 nie są obsługiwane przez usługę WCF w systemach, w których wymagane jest użycie algorytmów zgodnych ze standardem FIPS.

Algorytmy zgodne ze standardem FIPS mogą zakończyć się niepowodzeniem, jeśli rejestr jest edytowany

Można włączać i wyłączać algorytmy zgodne ze standardami FIPS (Federal Information Processing Standards) przy użyciu przystawki Programu Microsoft Management Console (MMC) zabezpieczeń lokalnych Ustawienia. Możesz również uzyskać dostęp do ustawienia w rejestrze. Należy jednak pamiętać, że program WCF nie obsługuje resetowania ustawienia przy użyciu rejestru. Jeśli wartość jest ustawiona na wartość inną niż 1 lub 0, niespójne wyniki mogą wystąpić między clR i systemem operacyjnym.

Ograniczenie szyfrowania AES zgodne ze standardem FIPS

Szyfrowanie AES zgodne ze standardem FIPS nie działa w wywołaniach zwrotnych dwudupleksowych pod personifikacją poziomu identyfikacji.

Certyfikaty CNG/KSP

Interfejs API kryptografii: Następna generacja (CNG) jest długoterminowym zamiennikiem interfejsu CryptoAPI. Ten interfejs API jest dostępny w kodzie niezarządzanych w systemach Windows Vista, Windows Server 2008 i nowszych wersjach systemu Windows.

Program .NET Framework 4.6.1 i starsze wersje nie obsługują tych certyfikatów, ponieważ używają starszego interfejsu CryptoAPI do obsługi certyfikatów CNG/KSP. Użycie tych certyfikatów w programie .NET Framework 4.6.1 i starszych wersjach spowoduje wyjątek.

Istnieją dwa możliwe sposoby na powiedzenie, czy certyfikat korzysta z dostawcy KSP:

Zabezpieczenia komunikatów kończą się niepowodzeniem, jeśli wymagane jest użycie personifikacji ASP.NET i zgodności ASP.NET

Program WCF nie obsługuje następującej kombinacji ustawień, ponieważ mogą uniemożliwić uwierzytelnianie klienta:

  • ASP.NET Personifikacja jest włączona. Odbywa się to w pliku Web.config przez ustawienie impersonate atrybutu><identityelementu na .true

  • ASP.NET tryb zgodności jest włączony przez ustawienie aspNetCompatibilityEnabled atrybutu <serviceHostingEnvironment> na true.

  • Używane są zabezpieczenia trybu komunikatów.

Obejście polega na wyłączeniu trybu zgodności ASP.NET. Ewentualnie, jeśli wymagany jest tryb zgodności ASP.NET, wyłącz funkcję personifikacji ASP.NET i zamiast tego użyj personifikacji dostarczonej przez program WCF. Aby uzyskać więcej informacji, zobacz Delegowanie i personifikacja.

Błąd adresu literału IPv6

Żądania zabezpieczeń kończą się niepowodzeniem, gdy klient i usługa znajdują się na tej samej maszynie, a adresy literału IPv6 są używane dla usługi.

Adresy IPv6 literału działają, jeśli usługa i klient znajdują się na różnych maszynach.

Błędy pobierania WSDL z federacyjnym zaufaniem

Program WCF wymaga dokładnie jednego dokumentu WSDL dla każdego węzła w łańcuchu zaufania federacyjnego. Należy zachować ostrożność, aby nie skonfigurować pętli podczas określania punktów końcowych. Jednym ze sposobów powstawania pętli jest użycie pobierania w języku WSDL łańcuchów zaufania federacyjnego z co najmniej dwoma linkami w tym samym dokumencie WSDL. Typowym scenariuszem, który może spowodować ten problem, jest usługa federacyjna, w której serwer tokenów zabezpieczających i usługa znajdują się wewnątrz tego samego hosta ServiceHost.

Przykładem takiej sytuacji jest usługa z następującymi trzema adresami punktów końcowych:

  • http://localhost/CalculatorService/service (usługa)

  • http://localhost/CalculatorService/issue_ticket (STS)

  • http://localhost/CalculatorService/mex (punkt końcowy metadanych)

Spowoduje to zgłoszenie wyjątku.

Ten scenariusz może działać, umieszczając issue_ticket punkt końcowy w innym miejscu.

Atrybuty importu WSDL można utracić

Program WCF traci śledzenie atrybutów elementu <wst:Claims> w szablonie RST podczas importowania WSDL. Dzieje się tak podczas importowania WSDL, jeśli określisz <Claims> bezpośrednio w WSFederationHttpBinding.Security.Message.TokenRequestParameters kolekcji typów oświadczeń lub IssuedSecurityTokenRequestParameters.AdditionalRequestParameters zamiast ich bezpośrednio. Ponieważ import traci atrybuty, powiązanie nie odbywa się prawidłowo za pośrednictwem języka WSDL i dlatego jest niepoprawne po stronie klienta.

Poprawka polega na zmodyfikowaniu powiązania bezpośrednio na kliencie po zakończeniu importowania.

Zobacz też