gdzie przechowywać poświadczenia użytkownika w aplikacji korporacyjnej (EAI)?

Question

Tło/Context

Rozwijamy usługi powiadamiania Event. Aplikacja na wysokim poziomie wygląda następująco:

Nasz zakres rozwoju obejmuje widget i ENS.

"ENS" działa jako centralny punkt gromadzenia określonych typów zdarzeń, które są interesujące dla użytkowników. Każdy użytkownik, który chce wiedzieć, kiedy występują tego typu zdarzenia, rejestruje się w usłudze ENS, , która identyfikuje zdarzenia w kolejności i dopasowuje powiadomienia do subskrypcji.

Użytkownik, który chce subscibe powinien być prawidłowy użytkownik Zintegrowany aplikacji (dB, system SAP etc)

sekwencję zdarzeń:

Teraz moje pytanie brzmi:

Jakie są najlepsze sposoby przechowywania danych użytkownika db, sap itp.

EDIT Jak często należy uwierzytelniać użytkownika? Powinien być za każdym razem, gdy dostarczane są wiadomości? (Jak wspomniano @duffymo, jeśli użyję tej strategii, wpłynie to na system źródłowy)

Dodatkowe informacje: ENS to serwisy internetowe.

ENS odpytuje SAP (i inne aplikacje) i tu problem staje się coraz bardziej złożony. W SAP istnieje autoryzacja na poziomie danych. Dlatego nie wszyscy użytkownicy mogą zobaczyć wszystkie zdarzenia/dane.

Jeśli SAP przekazał dane wraz z informacją o użytkowniku, który ma uprawnienia do wyświetlania, nie ma żadnych problemów.

Przypadek 1: Harmonogram jest inicjowana przez ENS

1. użytkownik prenumeruje do subskrypcji. W momencie subskrypcji użytkownik jest sprawdzany pod kątem autoryzacji w systemie SAP. Jeśli wszystko jest w porządku, będzie mógł otrzymać subskrypcję.
2. Program planujący działa w zaplanowanym czasie.
3. Program planujący identyfikuje użytkowników subskrybowanych.
4. Planista używa zapisanych poświadczeń użytkowników (pobranych w ENS) do POLL, jeśli zdarzenie wystąpiło.
5. Poinformuj użytkowników, jeśli nastąpiły zmiany.

Disadvs tutaj:

• poświadczenia użytkownika są przechowywane gdzieś zewnętrzny - zespół zabezpieczeń może nie akceptują go
• redundantne uderza jeśli więcej niż jeden użytkownik jest zapisany w tym samym kawałku informacji

Przypadek 2: Scheduler jest wywoływany przez WIDŻET. Kredyt użytkownika będzie przechowywany tylko na lokalnym komputerze użytkownika. Diadv:

• Jeśli subskrypcja jest codziennie, a jeśli system user/widżet nie jest gotowy. Użytkownikowi może brakować powiadomień , które miały miejsce, powiedzmy, w weekendy.
• Reduta trafi na serwer, jeśli więcej niż jeden użytkownik jest subskrybentem dla tej samej informacji o numerze .

Answer 1

Zwykle jest to aplikacja, która podała referencje do bazy danych, SAP itp. Poszczególni użytkownicy mieliby poświadczenia przechowywane w LDAP lub bazie danych; uwierzytelnienie i autoryzacja będą traktowane jako problem przekrojowy przez aplikację, serwer EAI lub urządzenie takie jak SiteMinder.

Przychodzące żądania będą przechwytywane i sprawdzane pod kątem tokenów autoryzacji. Jeśli token się nie pojawi, sprawdź uwierzytelnianie i autoryzację. Jeśli jest to dozwolone, utwórz token autoryzacji i umieść go w pamięci podręcznej.

Jest to standardowy scenariusz dla aplikacji internetowych. W przypadku takiej sytuacji powiadomienie o wydarzeniu, takie jak Twoje, jest bardziej skomplikowane. Będziesz musiał sprawdzić autoryzację, gdy użytkownik zasubskrybuje. Powinieneś powiadomić ich natychmiast, jeśli użytkownik nie jest uprawniony, ponieważ nie chcesz sprawdzać danych logowania przy każdym opublikowaniu. Musi istnieć powiązanie między użytkownikiem, subskrybowanym wydarzeniem i poświadczeniem autoryzacji.

Widzę tylko jeden problem.

Możesz wysyłać zdarzenia do nieautoryzowanego użytkownika, jeśli subskrybuje on wydarzenie, dowiaduje się, że jest uprawniony, odbiera pierwszą transmisję, a następnie z jakiegoś powodu zostaje nieautoryzowany. Sugeruje to, że będziesz musiał sprawdzać dane uwierzytelniające za każdym razem, gdy będziesz nadawać subskrybentom. Może to stać się uciążliwe i spowolnić działanie aplikacji.

Spójrz na standardy takie jak SAML, aby sprawdzić, czy może ci pomóc.

Problem z buforowaniem zależy od porównania czasu między zdarzeniami i zmianami autoryzacji. Jeśli czas między zdarzeniami jest długi w porównaniu ze zmianami autoryzacji, musisz za każdym razem sprawdzać, ponieważ nie masz możliwości sprawdzenia, czy autoryzacja została cofnięta od ostatniego zdarzenia.

Answer 2

W konfiguracji, którą opisujesz w pytaniu, będziesz musiał zbudować sposób na usunięcie kolejek komunikatów. Na przykład, co się stanie, gdy subskrybent będzie miał problemy i przestanie odbierać wiadomości lub co się stanie, jeśli przypadkowo niektóre źle sformatowane wiadomości zostaną pobrane z tematów subskrypcji, a te wiadomości spowodują, że klient otrzyma wiadomości z powodu awarii. Dlatego Twój system będzie musiał posiadać funkcje administracyjne, aby usuwać wiadomości.Możesz ponownie użyć tej funkcji administratora, aby wystrzelić użytkownika został usunięty komunikat z systemu zewnętrznego do ENS, ta wiadomość usunięta przez użytkownika spowodowałaby opróżnienie kolejki powiadomień użytkowników i unieważnienie ich subskrypcji.

Inną rzeczą, której można użyć do rozwiązania problemu w zewnętrznych systemach usuwania użytkownika, jest informowanie go o komunikatach z zewnętrznych systemów. Na przykład komunikat powiadomienia SAP może być ważny przez 2 godziny po czasie utworzenia. Jeśli użytkownik nie otrzyma wiadomości w ciągu 2 godzin, wiadomość zostanie usunięta. Jeśli połączysz wygaśnięcie wiadomości z powiadomieniami od SAP, że użytkownik nie jest już ważny, możesz wiedzieć, że istnieje limit czasu, w którym użytkownik zostanie unieważniony.

Myślę, że jeśli podasz więcej kontekstu na temat technologii, których używasz do wdrożenia ENS, będziemy mogli udzielić Ci bardziej konkretnych odpowiedzi.

Answer 3

Sposób, w jaki najczęściej widziałem ten wzorzec, polega na tym, że autoryzacja odbywa się w subskrypcji, a nie na zapleczu. Hierarchia tematu odzwierciedla model zabezpieczeń aplikacji zaplecza. Jeśli back-end ma funkcje do zapytań o Produce, Deli i Sklep spożywczy, istnieją węzły tematyczne o tych samych klasyfikacjach. Użytkownicy autoryzowani w systemie zaplecza dla Sklepu spożywczego są również uprawnieni do tematu "Artykuły spożywcze". Autoryzacje w systemie zaplecza mogą być okresowo eksportowane (często jest to nocna) i konwertowane na ustawienia autoryzacji w pubie/podrzędnym brokerze. W jednej z implementacji pracowałem nad systemem zaplecza, który publikowałby zmiany autoryzacji do pubu/sub-brokera na bezpiecznym temacie administracyjnym, aby autoryzacje abonentów były aktualizowane w czasie zbliżonym do rzeczywistego.

Pojęcie przekazywania referencji z powrotem do systemu źródłowego brzmi na pierwszy rzut oka bezpiecznie, ale przy głębszej inspekcji ma pewne problemy. Po pierwsze, w jaki sposób planujesz to skalować? Nigdy nie widziałem udanego systemu powiadamiania o zdarzeniach, który nie został w znacznym stopniu ponownie wykorzystany. Każdy system zaplecza będzie miał inne wymagania dotyczące uwierzytelniania, zwykle różne poświadczenia, różne wymagania dotyczące ważności i buforowania itd. Budowanie systemu w celu uzyskania poświadczeń z powrotem do kilku aplikacji zaplecza to jedno. Zrobienie tego za 10 czy 20 to koszmar.

Zakładając, że rozwiązałeś powyższe problemy, w jednym miejscu masz poświadczenia użytkownika z pamięci podręcznej dla połowy systemów korporacyjnych zaplecza. Jeśli ten jeden system centralny jest zagrożony, podobnie jak wszystkie systemy wewnętrzne, z którymi się komunikuje. Ten centralny system stał się najbardziej krytycznym punktem centralnym bezpieczeństwa w przedsiębiorstwie. Poważne bezpieczeństwo potrzebne do rozwiązania tego problemu jest kosztowne.

Tak, to jest ból w tyłku, aby drzewo tematu i autoryzacje pub/sub-broker odzwierciedlały model zabezpieczeń aplikacji zaplecza. Ale w końcu jest to o wiele łatwiejsze (i mniej kosztowne) niż zaprojektowanie centralnej usługi brokera wystarczająco bezpiecznej do przechowywania wszystkich poświadczeń, a także zdolnej do sprawdzania ich w kilku systemach zaplecza bez zagłuszania brokera lub systemów źródłowych, które publikują do tego.

Answer 4

LDAP będzie lepszym rozwiązaniem do przechowywania to bezpieczny i szybki, przenośny również

* EDIT: Portable w sensie dostępu do aplikacji korporacyjnych.