Niedawno udostępniliśmy usługę klientowi Java. Nasza usługa wykorzystuje zabezpieczenia transportowe wraz z weryfikacją nazwy użytkownika/hasła.Klienci Java WCF i IncludeTimestamp
Podczas próby połączenia się z naszą usługą klient otrzymywał wyjątek dotyczący nagłówków zabezpieczeń. Dalsze badania wykazały, że WCF oczekuje, że znacznik czasu będzie zawarty w nagłówku SOAP przekazanym od klienta. Jeśli to nie występuje (lub wariancja jest większa niż 5 minut), rzuci wyjątek.
Znaleźliśmy również, że klienci Java nie przechodzą znacznika czasu, który jest oczekiwany. Jedynym rozwiązaniem, które znaleźliśmy, było zaimplementowanie CustomBinding i ustawienie IncludeTimestamp na wartość false. Umożliwiło to klientowi skuteczne wywołanie usługi.
Dziś, patrząc w górę najlepszych praktyk w zakresie bezpieczeństwa z WCF widzę następujące na MSDN:
zestaw SecurityBindingElement.IncludeTimestamp True na niestandardowe Wiązania
Podczas tworzenia niestandardowego wiązania, ty musi ustawić wartość IncludeTimestamp na true. W przeciwnym razie, jeśli parametr IncludeTimestamp ma wartość false, a klient używa asymetrycznego tokenu opartego na kluczu, takiego jak certyfikat X509, , wiadomość nie zostanie podpisana.
Moje pytanie brzmi: jaka jest najlepsza praktyka podczas eksponowania usług WCF (i ostatecznie Web API) na świat zewnętrzny, jednocześnie wykorzystując SSL (Transport) do klientów innych niż .NET?
Istnieje wiele odmian między różnymi zestawami narzędzi serwisowych, nie jestem pewien, jaka jest najlepsza praktyka. Zauważyłem, że HTTPS z nazwą użytkownika w wiadomości lub z podstawowym uwierzytelnieniem jest kompatybilny z większością zestawów narzędzi. Nawet wtedy, jak znalazłeś, WCF błądzi po bardziej restrykcyjnej stronie, podczas gdy pakiety narzędziowe Java są lżejsze. WCF dodaje coraz więcej flag do niestandardowych powiązań, aby rozwiązać te problemy. – Sergey