Praktijken en inzichten over het implementeren van een uitnodigings- en roltoegangsbeheerfunctie zoals Logto Cloud-samenwerking in een multi-tenant applicatie.
Vorige week hebben we de samenwerkingsfunctie op Logto Cloud geïntroduceerd. Als je het hebt gemist, kijk dan even! Nu kun je collega's en medewerk(st)ers uitnodigen naar je bestaande Logto-tenants om samen te werken aan het beheren van het identiteitsysteem voor je applicaties.
In deze functierelease hebben we twee rollen toegevoegd aan elke Logto-tenant:
Consistent met onze inzet om onze eigen tools te gebruiken, hebben we gebruikgemaakt van onze RBAC (Role-Based Access Control) en Organisatie-functie voor het bouwen van gebruikerssamenwerking. Als je nieuw bent met RBAC, bekijk dan ons vorige bericht om aan de slag te gaan.
In deze blogpost kijken we naar wat er komt kijken bij het implementeren van deze functie, en hoe deze praktijken nuttig voor je kunnen zijn als je multi-organisatieapplicaties ontwikkelt.
Elke Logto Cloud-tenant fungeert als een onafhankelijke organisatie in ons systeem, aangedreven door onze eigen Organisaties-functie. Om de tenantbeheerder- en samenwerkerrollen te introduceren, hebben we twee organisatierollen gecreëerd in de organisatietemplate, elk toegewezen met een specifieke set organisatiepermissies.
We hebben een set management-API's met betrekking tot uitnodigingen in de organisaties-functie geleverd. Met deze API's kun je bijvoorbeeld:
POST /api/organization-invitations een organisatie-uitnodiging maken en verzenden naar een e-mailadresGET /api/organization-invitations & GET /api/organization-invitations/{id} je uitnodigingen opvragenPUT /api/organization-invitations/{id}/status de uitnodiging accepteren of weigeren door de uitnodigingsstatus bij te werkenVoor meer details, raadpleeg de volledige API-documentatie.
Omdat uitnodigingen via e-mail worden verzonden, zorg ervoor dat je e-mailconnector correct is geconfigureerd. In deze release hebben we een nieuw gebruikt type e-mailsjabloon geïntroduceerd, OrganizationInvitation, waarmee de uitnodigingse-mailsjabloon kan worden aangepast.
Deze e-mailsjabloon accepteert standaard een {{link}}-variabele, die de link naar de Logto Console's landingspagina is, waar de gebruikers de uitnodiging kunnen accepteren en deelnemen aan een Logto-tenant. Een van de landingspagina's in Logto Cloud ziet er uit zoals de onderstaande afbeelding:
Raadpleeg de API-documentatie voor meer details over het verzenden van de uitnodigingsmail via Management API.
Met de bovenstaande instellingen kunnen we via e-mail uitnodigingen versturen, en genodigden kunnen zich bij de organisatie aansluiten met de toegewezen rol.
Gebruikers met verschillende organisatierollen hebben verschillende scopes (permissies) in hun toegangstokens. Dus moeten zowel de clientapplicatie (Logto Console) als onze backendservices deze scopes controleren om zichtbare functies en toegestane acties te bepalen.
Goed, zover lijkt alles verbonden, en wat missen we nog?
Het beheren van scope-updates in toegangstokens omvat:
In Logto Cloud controleert de Console actief gebruikersscope met SWR verzoeken, en wij verlenen automatisch opnieuw toestemming wanneer een gebruiker tot beheerder wordt gepromoveerd.
Als je een vergelijkbare functie met RBAC implementeert, heb je een mechanisme nodig (bijvoorbeeld WebSocket of server-push gebeurtenissen) om je applicatie te informeren over scope-updates, waardoor opnieuw toestemming kan worden verleend of nieuwe toegangstokens kunnen worden uitgegeven. Logto zal ook meer webhooks bieden om hierbij te helpen in toekomstige updates.
Logto Cloud's multi-tenancy- en samenwerkingsfuncties maken gebruik van onze Organisaties-functie. Als je een vergelijkbare multi-tenancy app ontwikkelt, overweeg dan om deze functie met vergelijkbare benaderingen te gebruiken.
Ik hoop dat deze blogpost inzicht biedt. Voor vragen of discussies, voel je vrij om deel te nemen aan ons Discord-kanaal.