Control API - tenant administracja

FoxIDs ma oddzielne powierzchnie Control API dla operatorów wdrażania, którzy administrują tenants i dla tenant, którzy administrują własnym kontem. Użyj operacji operatora do udostępniania tenant i administracji międzytenant. Skorzystaj z operacji samoobsługowych, gdy integracja powinna ograniczać się do własnego tenant.

Przed wywołaniem tych operacji skonfiguruj Control API uwierzytelnianie i prawa dostępu. Swagger pozostaje dokładnym odniesieniem do właściwości tenant, planów i opcji płatności, reguł walidacji i schematów odpowiedzi:

API powierzchnie

Operator wdrożenia

Operacje operatorskie wywoływane są w master tenant:

https://control.foxids.com/api/master/master

Działanie	Punkt końcowy	Zamiar
Lista	`GET /!tenants`	Lista innych niż master tenants z opcjonalnymi filtrami i paginacją.
Dostawać	`GET /!tenant?name={name}`	Przeczytaj zasoby administracyjne użytkownika tenant.
Tworzyć	`POST /!tenant`	Udostępnij zasoby tenant, początkowego administratora i domyślne.
Aktualizacja	`PUT /!tenant`	Zastąp edytowalne właściwości tenant zarządzane przez operatora.
Usuwać	`DELETE /!tenant?name={name}`	Trwale usuń dane tenant i wszystkie dane tenant.

Te operacje wymagają praw dostępu master-tenant. Są one przeznaczone dla zaufanych usług administrowania wdrażaniem i udostępniania SaaS.

Tenant samoobsługa

A tenant wywołuje własne operacje poprzez swoje środowisko master:

https://control.foxids.com/api/{tenant_name}/master

Działanie	Punkt końcowy	Zamiar
Dostawać	`GET /!mytenant`	Przeczytaj konto tenant rozmówcy i dostępne ustawienia.
Aktualizacja	`PUT /!mytenant`	Zaktualizuj dozwolone usługi samoobsługowe.
Usuwać	`DELETE /!mytenant`	Trwale usuń dane rozmówcy tenant i wszystkie dane tenant.

Samoobsługa korzysta z praw dostępu tenant i nie może administrować innym tenant. Zmiany planu, ustawienia płatności i domeny niestandardowe również podlegają skonfigurowanym zasadom wdrożenia.

Zmień hosta w tych przykładach dla wdrożenia samodzielnego i wyślij token dostępu w nagłówku Authorization: Bearer {access_token}.

Wymień i zidentyfikuj tenants

GET /!tenants akceptuje filterName, filterCustomDomain i paginationToken. Jeśli dostępne są oba filtry, zwracany jest tenant, gdy pasuje zarówno jego nazwa, jak i domena niestandardowa. Rekordy master tenant i przeznaczone wyłącznie do użytku wewnętrznego tenant nie są uwzględniane.

Powtarzaj żądanie podzielone na strony z tymi samymi filtrami i zwróconym nieprzezroczystym tokenem, dopóki nie zostanie zwrócony żaden token. Nie interpretuj ani nie modyfikuj tokena.

Małe litery tenant name to stabilny identyfikator używany w adresach URL FoxIDs i Control API. Traktuj go jako niezmienny klucz automatyzacji. Domena niestandardowa to osobna właściwość routingu i marki i nie można jej używać jako nazwy trasy Control API tenant.

Zapewnij tenant

Tworzenie Tenant to złożona operacja udostępniania. Pomyślne żądanie tworzy:

rekord tenant;
środowisko master urządzenia tenant i jego domyślna metoda uwierzytelniania logowania;
początkowy użytkownik-administrator;
zasób Control API i aplikacja klienta sterującego;
domyślne środowiska skonfigurowane dla wdrożenia.

Początkowy administrator może otrzymać dostarczone hasło lub ustalić hasło za pośrednictwem skonfigurowanego przepływu poczty e-mail. Chroń podane hasło i nie rejestruj treści żądania.

Żądanie może również wybrać plan i zainicjować ustawienia klienta, oświadczenia i domeny niestandardowej, jeśli pozwala na to wdrożenie. Niepowtarzalność nazw Tenant, zasady planu, obsługa domen niestandardowych i wymagane dane administratora są sprawdzane przed zakończeniem udostępniania. Jeśli błąd konta lub danych zakłóca udostępnianie, FoxIDs próbuje wyczyścić zasoby utworzone przez to żądanie; niemniej jednak klienci powinni traktować wszelkie niepowodzenia jako nieudane i sprawdzać stan przed ponowną próbą z tą samą nazwą tenant.

Zaktualizuj ustawienia tenant

Operacje Tenant PUT to pełne aktualizacje, a nie łatki. Pobierz bieżący zasób, zachowaj wszystkie edytowalne właściwości, które powinny pozostać niezmienione, zastosuj zamierzoną zmianę i wyślij kompletny model żądania dla wybranego operatora lub samoobsługowego punktu końcowego.

Zasób operatora obejmuje właściwości zarządzane w ramach wdrożenia, takie jak przypisanie planu, weryfikacja domeny niestandardowej, konfiguracja użycia i płatności, waluta, podatek VAT, cena godzinowa i dane klienta. Zasób samoobsługowy udostępnia tylko ustawienia, którymi może zarządzać tenant.

Zmiana domeny niestandardowej poprzez samoobsługę oznacza domenę jako niezweryfikowaną do czasu zakończenia wymaganej weryfikacji. Wybrany plan musi obsługiwać domenę niestandardową. Użyj operatora API do zarządzania stanem weryfikacji; nie pozwól niezaufanemu klientowi tenant twierdzić, że jego własna domena została zweryfikowana.

Usuń tenant

Usunięcie Tenant jest nieodwracalne i kaskadowe. Usuwa każde środowisko w tenant i wszystkie aplikacje objęte zakresem, metody uwierzytelniania, użytkowników, sesje, granty, klucze i inne dane FoxIDs. Usuwa także konfigurację na poziomie tenant i routing domeny niestandardowej. Nie można usunąć master tenant. Dzienniki już wysłane do repozytorium zewnętrznego podlegają zasadom przechowywania i usuwania obowiązującym w tym repozytorium.

Przed usunięciem zatrzymaj ruch, wyeksportuj konfigurację lub dane, które muszą zostać zachowane, anuluj lub uzgodnij rozliczenia zewnętrzne, jeśli ma to zastosowanie, i zweryfikuj nazwę techniczną tenant. Wymagaj wyraźnego potwierdzenia w narzędziach operatora. Nie używaj usuwania tenant do tymczasowego blokowania dostępu; zamiast tego wyłącz lub zaktualizuj odpowiednich użytkowników, aplikacje lub metody uwierzytelniania.

Wskazówki dotyczące automatyzacji i bezpieczeństwa

Preferuj samoobsługowe punkty końcowe, gdy klient musi jedynie zarządzać swoim własnym tenant.
Ogranicz poświadczenia operatora do małej, zaufanej usługi udostępniania.
Zachowaj stabilność nazwy technicznej tenant i przechowuj ją niezależnie od danych wyświetlanych, klientów i domeny niestandardowej.
Użyj get-modify-put, aby nowe właściwości nie zostały zresetowane przez starszą integrację.
Użyj paginacji dla zasobów reklamowych tenant i uzgodnij według nazwy technicznej.
Traktuj tworzenie i usuwanie tenant jako długotrwałe złożone działania administracyjne; użyj odpowiednich limitów czasu klienta i zweryfikuj stan końcowy po przerwanej odpowiedzi.
Oczekuj, że żądania tworzenia, aktualizacji i usuwania pojawią się w dzienniku audytu kontroli. Operacje odczytu nie są zapisywane jako zdarzenia kontroli.

Typowe reakcje na błędy

400 Bad Request, gdy dane tenant, administratora, planu, płatności, klienta lub domeny niestandardowej są nieprawidłowe.
401 Unauthorized, gdy brakuje tokena dostępu lub jest on nieprawidłowy.
403 Forbidden, gdy wywołujący nie ma wymaganego prawa dostępu master lub tenant.
404 Not Found, gdy wybrane tenant nie istnieje.
409 Conflict, gdy istnieje już nazwa tenant lub inna unikalna wartość.

Użyj treści odpowiedzi, aby uzyskać szczegółowe informacje dotyczące sprawdzania poprawności, oraz Swagger UI w przypadku odpowiedzi zadeklarowanych przez każdą operację.