Achter de schermen: Hoe we gebruikerssamenwerking implementeren binnen een multi-tenant app

Achtergrond#

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:

• Beheerder: Volledige toegang tot de tenant, inclusief het beheren van identiteitsgerelateerde bronnen, het uitnodigen en beheren van andere leden, het afhandelen van betalingen en het bekijken van betalingsgeschiedenis.
• Samenwerker: Kan identiteitsgerelateerde bronnen beheren, maar heeft geen toegang tot andere beheerfuncties.

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.

Logto Cloud's samenwerking is gebouwd met Logto Organisaties#

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.

Uitnodigingen beheren met Logto Management API#

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-mailadres
• GET /api/organization-invitations & GET /api/organization-invitations/{id} je uitnodigingen opvragen
• PUT /api/organization-invitations/{id}/status de uitnodiging accepteren of weigeren door de uitnodigingsstatus bij te werken

Voor meer details, raadpleeg de volledige API-documentatie.

Verbind met je e-mailconnector#

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.

Gebruik RBAC om gebruikersrechten te beheren#

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?

Scope updates in toegangstokens beheren#

Het beheren van scope-updates in toegangstokens omvat:

• Bestaande scopes intrekken: Bijvoorbeeld, het degraderen van een beheerder naar een niet-beheerderssamenwerker verkleint automatisch de scopes in het nieuwe toegangstoken dat wordt verkregen met de bestaande vernieuwings-token.
• Nieuwe scopes toekennen: Omgekeerd vereist het promoveren van een gebruiker tot beheerder het starten van een opnieuweaanmeld- of opnieuwconsentproces om de wijziging in gebruikers toegangstokens te weerspiegelen.

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.

Samenvattend#

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.