WCF, zabezpieczenia i certyfikaty

Question

Mam aplikację WCF typu klient/serwer wymagającą pewnego rodzaju uwierzytelnienia użytkownika względem bazy danych. Aplikacja (zarówno klient, jak i serwer) jest opracowywana w celu sprzedaży dziesiątkom klientów do użytku w intranecie. Nie martwimy się zbytnio o szyfrowanie większości danych przesyłanych przez kabel, z wyjątkiem oczywiście podczas uwierzytelniania.

Myśląc o bezpieczeństwie WCF, wracam do pomysłu, że powinniśmy korzystać z certyfikatów x509. Jednak nasi klienci na pewno nie będą chcieli wiedzieć o żadnych szczegółach związanych z koniecznością ubiegania się, zakupu i instalacji tych certyfikatów.

Chciałbym wiedzieć przede wszystkim, jaka preferowana metoda polega na wdrożeniu uwierzytelniania nazwy użytkownika/hasła w tym scenariuszu. Jeśli będzie to wymagało użycia certyfikatów, czy klient musi ubiegać się o własne certyfikaty od zaufanego urzędu certyfikacji, czy możemy jako dostawca oprogramowania wygenerować certyfikaty, których klient może użyć?

Naprawdę szukam najlepszej praktyki, przy jak najmniejszym tarciu dla naszych klientów.

Dzięki!

Edytuj: Używam NetTcpBinding, a mój serwer działa jako usługa systemu Windows.

Answer 1

Tak więc nazwa użytkownika/hasła nie wymagają certyfikatów klienta, ponieważ jestem pewien, że jesteś tego świadomy, to po prostu wymaga certyfikatu HTTPS na serwerze obsługującym usługę WCF - kiedy już będziesz mógł z powodzeniem używać standardowej nazwy użytkownika/hasła auth bits (WCF nie zezwala na uwierzytelnianie oparte na wiadomości bez HTTPS).

Jeśli chciałbyś udać się do katalogu głównego certyfikatu klienta, uzyskasz przewagę niezaprzeczalności - możesz być pewien, że wysłanie urządzenia jest tym, za kogo się podaje (chyba że ktoś ukradł certyfikat, co jest mniej prawdopodobne niż kombinacja nazwy użytkownika i hasła przechodzenia). Ty jako dostawca oprogramowania możesz działać jako własny urząd certyfikacji i generować własne certyfikaty klienta (możesz to zrobić na kilka sposobów w zależności od infrastruktury), ale musisz skonfigurować klientów, aby zaufali twojemu głównemu urzędowi certyfikacji.

Jeśli serwer i klient działają w środowisku domenowym, możesz użyć transport security with Windows authentication (używasz powiązania tcp, więc interoperacyjność jest i tak poza tym oknem!) Dodatkową korzyścią jest to, że uwierzytelnienie jest przejrzyste, a Ty nie. • Potrzebują żadnych certyfikatów w dowolnym miejscu. Jeśli chcesz zweryfikować tożsamość serwera, to zrobi to message security with Windows authentication.

Answer 2

Jeśli zamierzasz przekroczyć granice zapory, certyfikaty będą najlepszym rozwiązaniem. Nie znam się na szczegółach dotyczących wniosków o certyfikaty lub aplikacji. Niestety, o ile wiem, myślę, że będziesz musiał pomóc im ubiegać się o certyfikaty lub będą musieli zrobić to samodzielnie, chyba że będą chcieli podjąć się instalacji własnego serwera certyfikatów. Jeśli aplikacja będzie wewnętrzna, wówczas uwierzytelnianie w systemie Windows będzie działało i jest BARDZO proste, ale jeśli uważasz, że będziesz mieć klientów, którzy korzystają z Twojej aplikacji przez granice zapory, równie dobrze możesz poświęcić czas na używanie certyfikatów, ponieważ certyfikaty będą działały wszędzie. Teraz jest coś, co nazywa się bezpieczeństwem federacyjnym, w którym delegujesz uprawnienia uwierzytelniania do innej jednostki. Myślę, że jest to używane, jeśli mówisz, że musisz domen i chcesz delegować uprawnienia, powiedz o kimś w innej domenie, która nie znajduje się w Twojej domenie, do swojej domeny, ale jest dość skomplikowana i moja wiedza na temat jej bardzo ograniczonego, ale brzmienia twoich wymagań Certyfikaty są drogą do zrobienia.

Security nie ma być łatwe :)

Answer 3

Mam projekt w produkcji, który jest podobny do scenariusza. Posiadam usługę Windows Hosting punktów końcowych za pośrednictwem netTCPBinding i korzystałem z certyfikatów x509 ... chociaż w moim przypadku celem było zaszyfrowanie zarówno warstw transportu, jak i wiadomości, ponieważ przekraczałem niezaufane granice bezpieczeństwa. W mniejszym stopniu chodziło mi o zapewnienie uwierzytelniania/autoryzacji innych niż wymaganie obecności certyfikatu.

Podobnie jak w scenariuszach intranetowych (zakładam), miałem uprawnienia do serwera i komputerów klienckich w czasie instalacji ... lub przynajmniej mogłem dyktować niektóre warunki instalacji.

Zamiast kupować certyfikaty x509 i obciążać klienta tym wydatkiem, zdecydowałem się wypuścić na rynek własny. Skonfigurowaliśmy jeden z naszych serwerów Win2003 jako CA, wydając nasz własny certyfikat urzędu certyfikacji. Następnie wygenerowaliśmy certyfikat x509 dla serwera, a także indywidualne certyfikaty x509 dla klientów.

Certyfikaty klienta i serwera zostały zainstalowane na klientach i serwerze (odpowiednio) w osobistym magazynie użytkownika na poziomie komputera. Zainstalowaliśmy również nasz certyfikat CA bezpośrednio w sekcji Zaufane główne urzędy certyfikacji, dzięki czemu nasze certyfikaty klienta i serwera są zaufane.

Ponieważ mniej interesowało mnie uwierzytelnianie/autoryzacja, nie wiem, co polecić jako najlepszą praktykę w radzeniu sobie z wiążącymi certyfikatami dla poszczególnych użytkowników i przechodzeniu bardziej szczegółowym niż na poziomie komputera (moim rozwiązaniem była usługa Windows dla systemu Windows komunikacja serwisowa - całkowicie bez opieki). Sądzę, że potrzebujesz certyfikatu dla każdego użytkownika, instalując go w swoim osobistym magazynie użytkownika w certyfikatach MMC. Implementacja środowiska wykonawczego będzie opierała się na sposobie konfigurowania WCF do wyszukiwania certyfikatów, więc powinno być dość łatwe.

Podczas całego procesu opierałem się na tym, czego się nauczyłem z tego świetnego artykułu CodeProject: Securing WCF Services with Certificates. Przeprowadza Cię przez generowanie/instalowanie certyfikatów. Przykładowa aplikacja do WCF jest hostowana przez IIS, ale udało mi się dość łatwo przetłumaczyć sekcje konfiguracji z web.config na app.config.

W moim przypadku udostępniłem interfejs WWW do żądania certyfikatów w Win2003 do samej sieci, aby klient mógł żądać certyfikatów bezpośrednio w przyszłości. Mamy kontrolę zatwierdzania, więc działa dobrze. Nie miałem jeszcze potrzeby generowania nowych certyfikatów, więc nie jestem w stanie określić, jakie tarcie by to pociągnęło.