Rest API z bazy danych multi-tenant oddzielone przez klienta

Question

Mam bazę danych multi-tenant z kompozytu klucza

clientId - docId 

Routing wygląda to

/api/controller/clientId/docId 

przypadku uwierzytelniania używam „globalne "nazwa użytkownika, taka jak adres e-mail + hasło, wysłana w nagłówku http każdego żądania za pośrednictwem protokołu HTTPS. Nazwa użytkownika jest jawnie przypisywana do klienta i jest dostępna w zapleczu.

Co jest najlepszym sposobem, aby zrobić to prawidłowo z resztą i mieć najlepsze zabezpieczenie?

1. Route jak powyżej i po prostu sprawdzić, czy ClientID według nazwy użytkownika jest taka sama, niż w routingu

lub

1. Zmian routing jak poniżej i uzyskać ClientID z baza danych przed zapisaniem rekordu?

   /api/controller/docId

To może być oczywiste pytanie, ale martwię się o potencjalnych problemów bezpieczeństwa. A może po prostu nie masz pojęcia, co zrobić z krótszym routingiem?

Dzięki!

Answer 1

Myślę, że /api/controller/docId jest prawdopodobnie najlepszym pomysłem lub użyć pojedynczego zastępczego klucza do reprezentowania ClientId i docId (moje preferencje).

Jeśli nie musisz pozwalać klientom na przeglądanie zasobów innych klientów, ukryłbym to przed schematem URI, w najgorszym wypadku może być uważany za wyciek informacji w najlepszym razie jest zbędny, ponieważ uwierzytelniłeś klienta i wiesz, kim on jest. . Jest to również obciążenie ogólne, tzn. Nadal musisz sprawdzić, czy identyfikator klienta w adresie URL jest odwzorowany na nazwę użytkownika i hasło żądania, tak więc i tak musisz pobrać identyfikator klienta dla każdego żądania.

Jeśli przyjrzeliśmy się działaniu innych środowisk z wieloma najemcami, np. Sales Force widzi, że musi wywnioskować klienta za pomocą mechanizmu bezpieczeństwa lub ma szczęście posiadania unikalnego identyfikatora dla każdego obiektu/zasobu.

Podejście, które widziałem, polega na umieszczeniu identyfikatora klienta (zwykle jest to zastępczy klucz o nazwie somekind, unikanie wystawiania identyfikatorów innych użytkowników) w katalogu głównym adresu URL, np./api/{clientId}/controller/docId. W środowisku z wieloma dzierżawcami każdy zasób jest prawdopodobnie z definicji unikalny dla tego klienta.

Powodem czasami podane dla tego podejścia jest to, że ma unikatowy adres URL za asysty klientowi buforowanie .../api/{ClientID}/kontroler/docId lub/api/kontroler/{ClientID}/docId

Krótka notatka o podstawowym uwierzytelnieniu

Nic złego w twoim podejściu, ale zastanów się ... możesz pobrać identyfikator klienta podczas sprawdzania hasła i nazwy użytkownika i dodać to jako roszczenie do praw. Przynajmniej to jest wtedy dostępne w kodzie bez dalszych wyszukiwań db, aby go znaleźć (w ciągu życia tego żądania).

Idąc dalej, zastanów się nad dwuetapowym mechanizmem uwierzytelniania, w którym wydawany jest token (po poprawnej nazwie użytkownika i haśle) z identyfikatorem klienta w tokenie jako roszczeniem. Dzięki temu kolejne żądania z tokenem nie będą wymagały wywoływania bazy danych dla każdego żądania uwierzytelnienia i pobrania informacji. Spójrz na tokeny okaziciela OAuth http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (pamiętaj, aby je podpisać) lub niektóre z innych podejść ...

Answer 2

Podejście Marka jest całkowicie poprawne, jednak zdarza mi się używać /tenant/docid, ponieważ każdy lokator ma inną bazę danych. Jeśli nie zawierasz dzierżawcy w URI, to byłby prawdziwy ból próbujący zdecydować, do której bazy danych się podłączyć i polować na dokument.