SOA Service Design/Authentication

Question

Jestem raczej nowy w SOA i dlatego eksperymentuję.

Obecnie ta część, która tworzy największy problem dla mnie jest uwierzytelnianie, moja obecna myśl o tym obejmuje następujące elementy:

klient wysyła jakieś wiadomości uwierzytelniania do usługi uwierzytelniania/użytkownika, usługa ta odpytuje db i jeśli użytkownik zostanie znaleziony, a hasło jest prawidłowe, odpowie z identyfikatorem sesji, ten identyfikator będzie używany we wszystkich dalszych żądaniach tego klienta.

Wydaje mi się, że jestem w porządku, ale nie wiem, jak powinienem obsłużyć wnioski do innych służb, myślałem o trzech różnych podejściach.

1. Każda usługa pyta usługę uwierzytelniania, jeśli sesja jest ważna, a jeśli tak, to jakie role użytkownik jest w. Usługa uwierzytelniania wygląda w db i odpowiada odpowiednio.

2. Usługa uwierzytelniania przechowuje wszystkie informacje o sesji w pamięci RAM i odpowiada bez żądania db do żądań.

3. Usługa uwierzytelniania wysyła autoryzowaną wiadomość do esb, esb przekazuje tę autoryzowaną wiadomość do każdej usługi i te usługi ją buforują. Żadne dalsze żądania do usługi uwierzytelniania nie będą konieczne. Jeśli użytkownik wyloguje się lub zmieni się jego rola, inna wiadomość zostanie wysłana i przetworzona przez wszystkie usługi.

Myślę, że pierwsze podejście powoduje zbyt duży nacisk na usługę uwierzytelniania/db, ale podejmuje najmniej wysiłku w celu wdrożenia.

Drugi jest nadal bardzo łatwy w implementacji, ale nacisk na usługę uwierzytelniania pozostaje prawie taki sam.

Trzeci jest nieco bardziej skomplikowany do wdrożenia, ale skróciłby czas reakcji, ponieważ nie ma żadnych wycieczek do usługi uwierzytelniania. Jednak, jeśli istnieje zbyt wiele informacji o sesji, to takie podejście byłoby po prostu nieudane, a skalowalność jest mało prawdopodobna.

Answer 1

Najlepszym rozwiązaniem powinno być tak, jeśli wszystkie usługi są wewnętrzne,

1. Usługa uwierzytelniania wystawia token Klientowi usługi.
2. Klient usługi zawiera token w komunikacie SOA zawiniętym w WS-Security lub coś podobnego.
3. Usługa powinna potwierdzać token za pomocą usługi uwierzytelniania przed dostarczeniem usługi.

W przypadku usług zewnętrznych sugeruję przeglądanie rozwiązań federacyjnych, takich jak SAML.

Answer 2

Nie należy przeprowadzać optymalizacji przedwczesnej. Twoja opcja nie. 3, które uznajesz za bardziej skomplikowane do wdrożenia, jest niepotrzebne. Wybierz opcję nr. 2 jeśli to jest to, co możesz szybko wdrożyć. Możesz profilować później i to zmienić, ale założyłbym się, że nie będziesz miał "wąskiego gardła" podczas wybierania opcji 2.