Planiranje multi-tenant SaaS arhitekture: autentifikacija, organizacije i granice podataka

Autentifikaciji, članstvu, pozivnicama i naplati potrebne su granice organizacije u modelu podataka i u sesiji, a ne samo u korisničkom interfejsu.

Aktivna organizacija vezana za sesiju

API i korisnički interfejs treba da određuju aktivnu organizaciju iz sesije, a ne iz proizvoljnog ID-ja koji šalje klijent. To jedno pravilo sprečava većinu curenja podataka između tenanta i pojednostavljuje autorizaciju.

Sprovodite granice dvaput

Svaka tabela u vlasništvu tenanta sadrži ključ organizacije. Provere u aplikaciji filtriraju po njemu, a pravila baze podataka ga ponovo sprovode, tako da jedan propušten filter ne postane curenje podataka. Testovi namerno pokušavaju pristup između tenanta.

Članstvo i uloge kao deo proizvoda

Pozivnice, administratorske uloge i lične organizacije su funkcionalnosti proizvoda. Tretirajte ih sa istom pažnjom kao tokove namenjene korisnicima: jasna stanja, iskrene poruke o greškama i testovi oko teških putanja.

Naplata leži na istoj granici

Pretplate su vezane za organizacije. Osmislite to rano, čak i ako naplatu isporučujete kasnije; naknadno uvođenje tenancy-ja u naplatu košta više nego ostavljanje čiste granice.

Migracija postojećeg proizvoda

1. Dodajte ključeve organizacije u tabele u vlasništvu tenanta.
2. Popunite postojeće podatke u podrazumevanu organizaciju za svakog klijenta.
3. Sprovedite ključeve u upitima i pravilima baze podataka.
4. Uklonite stare putanje u kodu kada testovi prođu na podacima nalik produkcionim.

Studija Ledger opisuje kako smo izgradili autentifikaciju, autorizaciju i pretplate u finansijskom proizvodu. Za planiranje arhitekture pogledajte usluge razvoja proizvoda i arhitekture.