Σε ένα B2B portal, η κεντρική ομάδα δεν μπορεί να δημιουργεί χειροκίνητα κάθε νέο χρήστη για κάθε πελάτη. Η φυσική λύση είναι να επιτρέπεται σε έναν organization admin του πελάτη να προσκαλεί συναδέλφους και να τους αναθέτει ρόλους.
Αυτή η ευκολία δημιουργεί σοβαρό boundary: ο delegated admin πρέπει να διαχειρίζεται μόνο τη δική του εταιρεία και να μην μπορεί να αποδώσει δικαιώματα μεγαλύτερα από όσα επιτρέπεται. Το invitation flow είναι μέρος του authorization model, όχι απλώς ένα email με link.
User identity και organization membership
Η ταυτότητα χρήστη πρέπει να διαχωρίζεται από τη συμμετοχή του σε organization. Ο ίδιος άνθρωπος μπορεί να ανήκει σε περισσότερες εταιρείες με διαφορετικό ρόλο σε καθεμία.
Ένα χρήσιμο μοντέλο περιλαμβάνει:
- User ως καθολική ταυτότητα,
- Organization ή tenant,
- Membership που συνδέει user και organization,
- Role assignment scoped στο membership,
- Invitation πριν δημιουργηθεί ή ενεργοποιηθεί membership.
Μην αποθηκεύετε έναν μοναδικό global_role στον user αν τα δικαιώματα αλλάζουν ανά εταιρεία. Η Auth0 επίσης διαχωρίζει organization member roles από ρόλους που ανατίθενται γενικά στον χρήστη, κάτι που αποτυπώνει αυτή την ανάγκη.
Ποιος μπορεί να προσκαλέσει
Το permission invite_members πρέπει να αξιολογείται μέσα στο τρέχον organization context. Το backend δεν εμπιστεύεται organization_id που έστειλε το browser χωρίς να ελέγξει ότι ο actor είναι ενεργό μέλος με το σωστό permission.
Ο delegated admin μπορεί να προσκαλεί μόνο επιτρεπόμενα domains ή οποιοδήποτε email, ανά πολιτική πελάτη. Οι εξαιρέσεις χρειάζονται σαφή configuration. Μην συμπεραίνετε organization μόνο από το domain του email, επειδή consultants, subsidiaries και shared domains είναι συνηθισμένα.
Για ευαίσθητα tenants μπορεί να απαιτείται δεύτερη έγκριση ή company owner approval πριν ενεργοποιηθεί νέο membership.
Invitation token και lifecycle
Η πρόσκληση χρειάζεται τυχαίο, single-use token με expiry. Στη βάση αποθηκεύεται hash του token και metadata:
- organization και invitee email,
- inviter και επιλεγμένοι ρόλοι,
- created_at και expires_at,
- status pending, accepted, revoked ή expired,
- accepted_by user ID και χρόνο αποδοχής.
Το link πρέπει να οδηγεί σε canonical HTTPS domain και να μην περιλαμβάνει περισσότερα προσωπικά δεδομένα από όσα χρειάζονται. Η Auth0 τεκμηριώνει invitation ID μαζί με organization context που μεταφέρεται στη διαδικασία authorization. Ανεξάρτητα από provider, το server πρέπει να επαληθεύει ότι token, organization και application ταιριάζουν.
Η επαναποστολή δεν πρέπει να δημιουργεί απεριόριστα ενεργά tokens. Μπορεί να ακυρώνει το προηγούμενο ή να διατηρεί ένα ενεργό invitation με νέο delivery event.
Αποδοχή από υπάρχον ή νέο user
Όταν ανοίγει το link, ο invitee πρέπει να συνδεθεί ή να δημιουργήσει λογαριασμό. Το authenticated email πρέπει να ταιριάζει με το email της πρόσκλησης, εκτός αν υπάρχει ρητή enterprise identity policy.
Μετά την αποδοχή, το backend δημιουργεί membership atomically και μαρκάρει το token consumed. Δύο παράλληλα clicks δεν πρέπει να δημιουργήσουν διπλά memberships. Αν ο χρήστης είναι ήδη μέλος, η ροή εξηγεί την κατάσταση και δεν επανεφαρμόζει αυθαίρετα ρόλους.
Για SSO organizations, η πρόσκληση μπορεί να δρομολογεί στο σωστό identity provider. Το membership όμως παραμένει server-side απόφαση και δεν βασίζεται μόνο σε claim που έστειλε το client.
Role ceiling και privilege escalation
Ο delegated admin δεν πρέπει να μπορεί να αναθέσει role ανώτερο από το επιτρεπόμενο ceiling του. Το σύστημα χρειάζεται assignable roles policy ανά actor role ή organization plan.
Παραδείγματα:
- billing_admin μπορεί να προσκαλέσει billing_viewer αλλά όχι owner,
- organization_admin μπορεί να διαχειριστεί members αλλά όχι να αλλάξει contract owner,
- κανείς δεν μπορεί να αναβαθμίσει τον εαυτό του μέσω γενικού membership endpoint,
- ο τελευταίος owner δεν αφαιρείται χωρίς μεταβίβαση ownership.
Το UI εμφανίζει μόνο επιτρεπόμενες επιλογές, αλλά ο έλεγχος γίνεται ξανά στο API. Bulk invitations εφαρμόζουν policy σε κάθε invitee και αποτυγχάνουν με σαφή, ασφαλή τρόπο.
Αλλαγή ρόλου, αναστολή και αφαίρεση
Η διαχείριση δεν τελειώνει στην πρόσκληση. Ο admin χρειάζεται να αλλάξει ρόλο, να αναστείλει πρόσβαση ή να αφαιρέσει μέλος. Κάθε ενέργεια πρέπει να έχει consequences preview: ποιες εφαρμογές, ομάδες ή πόροι επηρεάζονται.
Η αφαίρεση membership πρέπει να ανακαλεί ενεργές sessions και long-lived tokens για το συγκεκριμένο organization. Δεν πρέπει απαραίτητα να διαγράφει τον καθολικό user, γιατί μπορεί να ανήκει αλλού.
Για υψηλού αντίκτυπου ρόλους, χρησιμοποιήστε step-up authentication και notifications στον company owner. Οι αλλαγές αφήνουν audit trail με actor, subject, previous role και new role.
Multi-tenant isolation
Κάθε query σε memberships, invitations και roles φιλτράρεται από server-resolved tenant context. Αποφύγετε endpoints όπου ο client αλλάζει απλώς organization ID και λαμβάνει δεδομένα άλλου πελάτη.
Οι δοκιμές πρέπει να περιλαμβάνουν intentional cross-tenant IDs, stale sessions μετά την αφαίρεση, invitation από άλλο tenant και role IDs που δεν ανήκουν στο organization. Τα object identifiers δεν είναι μυστικά και δεν αποτελούν authorization.
Τα background jobs και emails πρέπει επίσης να διατηρούν tenant context. Ένα invitation template δεν πρέπει να τραβήξει branding ή sender από λάθος organization.
Audit και self-service ιστορικό
Καταγράψτε invitation created, resent, revoked, accepted, membership suspended, role changed και member removed. Το organization admin μπορεί να βλέπει κατάλληλο ιστορικό για τη δική του εταιρεία, ενώ η πλατφόρμα διατηρεί ευρύτερο security audit.
Μην καταγράφετε raw invitation tokens. Χρησιμοποιήστε invitation ID και masked email όπου αρκεί. Alerts μπορούν να εντοπίζουν μεγάλο αριθμό invitations, επαναλαμβανόμενα expired links ή απόπειρες ανάθεσης απαγορευμένου role.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε identity, membership και role assignment ως ξεχωριστές έννοιες. Υλοποιούμε tenant-scoped APIs, single-use invitations, role ceilings και server-side checks σε κάθε αλλαγή, μαζί με άμεση ανάκληση πρόσβασης.
Προσθέτουμε καθαρό self-service admin UI, SSO-aware acceptance, audit trail και tests για cross-tenant επιθέσεις. Έτσι η Ai Foundry δημιουργεί B2B portals που μειώνουν τη χειροκίνητη υποστήριξη χωρίς να δίνουν στους πελάτες απεριόριστη ή ασαφή εξουσία πάνω στην πλατφόρμα.
Checklist πριν το launch
- Είναι ξεχωριστά user, organization και membership;
- Τα roles είναι scoped ανά organization;
- Τα invitation tokens είναι single-use, hashed και λήγουν;
- Το authenticated email επαληθεύεται στην αποδοχή;
- Ο inviter έχει role ceiling;
- Μπλοκάρεται self-escalation και αφαίρεση τελευταίου owner;
- Η αφαίρεση membership ανακαλεί sessions;
- Υπάρχουν cross-tenant security tests και audit events;
Το delegated administration πετυχαίνει όταν ο πελάτης μπορεί να εξυπηρετεί την ομάδα του μόνος του, μέσα σε όρια που είναι σαφή, ελέγξιμα και τεχνικά επιβεβλημένα.