(no title)
satyrnein | 9 months ago
Users exclusively belong to Organizations; every User belongs to exactly one Organization.
But I also see a screenshot where, after login, the User has to choose an organization or to create a new one. It seems to me that you support Users and Organizations in a many-to-many relationship, is that correct?
At my work, we landed on the terminology of Users, Memberships, and Accounts to describe this (a User can have Memberships to multiple Accounts, an Account can have multiple Members, etc). As a result, you don't "delete a user", you "revoke a membership".
noleary|9 months ago
Yeah, this is a line I wrote and could probably improve the clarity on. It's worth distinguishing the Tesseral concept of a User from the sense in which we might colloquially refer to a user. Some other people call the equivalent of a Tesseral User a Member or something similar.
An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization.
That is, there's support for a given person with a given email address to participate in different workspaces, but each workspace will have a different instance of a User.
nightpool|9 months ago
I don't think new auth services should encourage this pattern and I highly recommend that you remove this restriction as soon as possible before it becomes even more baked in. Your downstream services should have access to all of the orgs a user belongs to right from the beginning, using a comma-separated list or multi-value headers or something similar. Don't shard user IDs in this way.
theogravity|9 months ago
Then you can define applications (which are mapped 1:1 to tenants) where a user has a registration entry against that application, where a user can be referenced by their global user id, or application-specific user id.
Applications are OAuth2 applications (meaning a dedicated client id / secret), so we only create a single application and tenant, and maintain organization segmentation on our own application / db side instead.
(We're paying customers of FusionAuth. Anyone from FusionAuth, feel free to correct me.)
codegeek|9 months ago
This will be extremely confusing. You should simplify it and just keep the concept of User as we usually do. A user should have access to 1 or more organizations. That's it. You should rethink this otherwise it will be too confusing.
tmaier|9 months ago
One identity can have multiple users (one for each organization) At the same time, a user can have multiple identities. (e.g. username/password, Google oAuth, SAML etc.)
2Gkashmiri|9 months ago
Auth backend for an online accounting software.
An "admin" user creates orgs. Invites 3 other users.
Then there are orgs with multiple admins, multiple users, single user is member of multiple orgs by invite.
Like we have GitHub orgs.
Moto7451|9 months ago