Praktiker och insikter om implementering av en inbjudan och rollstyrelsehanteringsfunktion som Logto Cloud-samarbete i en multi-tenant-applikation.
Förra veckan introducerade vi samarbetsfunktionen på Logto Cloud. Om du missade det, ta en titt! Nu kan du bjuda in kollegor och medarbetare till dina befintliga Logto-tenants, och samarbeta tillsammans med att underhålla identitetssystemet för dina applikationer.
I denna funktionsrelease har vi lagt till två roller till varje Logto-tenant:
I linje med vårt engagemang för att använda våra egna verktyg har vi använt vår RBAC (rollbaserade åtkomstkontroll) och Organisationsfunktion för att bygga användarsamarbete. Om du är ny på RBAC, kolla in vårt tidigare inlägg för att komma igång.
I detta blogginlägg ska vi ta en titt på vad som gick in i implementeringen av denna funktion, och hur dessa metoder kan gynna dig om du utvecklar multi-organisationsapplikationer.
Varje Logto Cloud-tenant fungerar som en oberoende organisation i vårt system, som drivs av vår egen Organisationsfunktion. För att introducera tenant-administratörs- och medarbetarrollarna skapade vi två organisationsroller i organisationens mall, var och en tilldelad med en specifik uppsättning av organisationsbehörigheter.
Vi har tillhandahållit en uppsättning av inbjudningsrelaterade Management APIs i organisationsfunktionen. Med dessa APIer kan du till exempel:
POST /api/organization-invitations skapa och skicka en organisationsinbjudan till en e-postadressGET /api/organization-invitations & GET /api/organization-invitations/{id} få dina inbjudningarPUT /api/organization-invitations/{id}/status acceptera eller avvisa inbjudan genom att uppdatera inbjudningsstatusenFör mer information, hänvisa till den fullständiga API-dokumentationen.
Eftersom inbjudningar skickas via e-post, se till att din e-postanslutning är korrekt konfigurerad. I denna release introducerade vi en ny typ av användning av e-postmall, OrganizationInvitation, som möjliggör anpassning av e-postinbjudansmall.
Denna e-postmall kommer att acceptera en {{link}}-variabel som standard, vilket är länken till Logto Consoles landningssida, där användarna kan acceptera inbjudan och gå med i en Logto-tenant. En av landningssidorna i Logto Cloud ser ut som skärmdumpen nedan:
Se API-dokumentationen för mer information om hur du skickar inbjudningsmejlet via Management API.
Med ovanstående inställningar kan vi skicka inbjudningar via e-post och de inbjudna kan gå med i organisationen med den tilldelade rollen.
Användare med olika organisationsroller kommer att ha olika scopes (behörigheter) i sina åtkomsttokens. Således bör både klientapplikationen (Logto Console) och våra backend-tjänster kontrollera dessa scopes för att bestämma synliga funktioner och tillåtna åtgärder.
Okej, hittills verkar allt kopplat, och vad mer saknar vi?
Hantering av omfångsuppdateringar i åtkomsttokens innebär:
I Logto Cloud kontrollerar Consolen aktivt användarscopes med SWR förfrågningar, och vi auto-samtycker när en användare befordras till administratör.
Om du implementerar en liknande funktion med RBAC behöver du en mekanism (t.ex. WebSocket eller server-push-händelser) för att meddela din applikation om omfångsuppdateringar, vilket möjliggör om-samtycke eller utfärdande av nya åtkomsttokens. Logto kommer också att tillhandahålla fler webhooks för att assistera med detta i framtida uppdateringar.
Logto Clouds multi-tenancy och samarbetsfunktioner utnyttjar vår Organisationsfunktion. Om du utvecklar en liknande multi-tenant-app, överväg att använda denna funktion med liknande tillvägagångssätt.
Jag hoppas att detta blogginlägg visade sig insiktsfullt. För frågor eller diskussioner, känn dig fri att ansluta dig till vår Discord-kanal.