Hello ,
I started implementing OIDC for Digicirco ( [belgian] cross platform ERP for local food systems where OFN is the sales platform) and it made me think about API and architecture , OIDC is a very standardized API (and thatâs good !!). Iâm also interacting with Farm Connect (France, ThĂŠo-Paul).
Letâs think high level. If you look at ebay, airbnb, amazon, everybody can buy and sell. Itâs not specific for an enterprise. So the main concept here for me would be an account. So an account can buy and sell (spoiler alert, account will be replaced by workspace later on, account concept is too much linked with a single member).
Now imagine, I, as a person, am buying local food for my family. But now I want to start a garden and sell some of my produce to my neighbour. How do I do not to mix orders for seeds from a local seed grower and my family orders ? Should I create a new account or introduce a new concept : workspace. Workspaces are cool : look at slack workspace, notions workspace. You can create as many as you want and invite people to it. But how do you make sure people are who they claim they are (important for trust especially when money gets involved) ⌠you canât in google and slack, I can be Olivier in the first workspace and Ned in the other. For instance, airbnb wants a single workspace/account per person, so they want to enforce identity. Enforcing identity is often taken at an administrative zone level (national, âŚ) : registering a person at birth, registering a business (an enterprise). So there are ways to make sure a person is a real person and a business is a real business. Since OFN uses the concept enterprise so I take it and I add the concept of person (very much the same as a user but an identified one and making sure there are no duplicates). I keep in mind that my garden project can very well become an enterprise later on (itâs a bit like turning a workspace into an enterprise workspace).
So we have workspaces, persons and enterprises. Persons are linked to enterprises (legally : employee, member, âŚ) and enterprises are linked to enterprises (legally as well : consortium, cooperative, âŚ). Letâs say a workspace can have multiple members. Since more and more horizontal hierarchy is the way to go (you donât have a boss, you have a coordinator). Letâs put all enterprises at same level and put their members at the same level too. Members have roles inside an enterprise and an enterprise can ask to play a role for another enterprise.
(schema.org uses to concept of organization, same as enterprise)
(workspace concept is also pretty good to create test workspaces)
[technical]
How to use all this with oauth / OIDC ?? And practically implement it in keycloak (https://www.ory.sh/ seems very promising !!) ?
The way I did it in keycloak (single realm) :
An workspace is a keycloak group (small generated id as group name) and a person is a user. So I can say this person belongs to this workspace by adding his user to the group related to the workspace.
(A pity you canât add a role to the membership in keycloak âŚ) Each platform/domain is represented by a client in keycloack. I created the resource type âworkspaceâ so I can add a specific workspace resource to a client and give it some scopes such as shipment:handle meaning I give the shipping platform the rights to handle the shipping of my small garden workspace. Based on the role of the user (realm role or client role), I can decide which scopes he gets.
The user OIDC token has a groups attribute (part of OIDC standards), array of workspace urls (example: https://digicirco.org/workspaces/riv2tncjAfw)