Status meetings
...
It is debatable whether
multi-tenant
is appropriate to describe this feature, but the name has stuck, so we’re using it.role
is used as a critical feature of authorization . Perhapsgroup
would be more appropriate, or at least natural, butrole
is what Auth0 provides out-of-the-box, so we'll go with it.in this requirements document. Auth0 provides the capability to create users, roles, and user-role associations. In this requirements document, we will use role-related terms as follows:Score role
: One of the built-in Score roles (Admin+Developer, Admin+End User, Developer, and End User)Auth0 role
: A role defined in Auth0tenant
: An Auth0 role defined for the purposes of enabling the requirements expressed in the document.role
: The meaning could be any of the above depending on the context in which it is used. Jim Wilson recommends avoiding use ofrole
in favor of one of the three terms above.
access BIEs
refers to creating, editing, viewing, and expressing BIEs (anything with BIEs)
...
For each BIE
For each of the BIE’s business contexts
For each of the business context’s roles
Is the user in that role?
Yes: Show the BIE in the list.
No: Don’t show the BIE in the list
Concrete example
Roles
...
Score roles
...
Score role | Auth0 role |
---|---|
Admin + Developer | Score_Admin_Developer |
End User + Developer | Score_Admin_End_User |
Developer | Score_Developer |
End User |
...
AgGateway (tenant)
...
ACME Brick (tenant)
...
HR Open Standards (tenant)
Score_End_User |
Example tenants
Tenant | Auth0 role |
---|---|
AgGateway | Score_Tenant_AgGateway |
ACME Brick | Score_Tenant_ACME_Brick |
HR Open Standards | Score_Tenant_HR_Open_Standards |
Business contexts
Human Resources
Agriculture
Construction
Entertainment
Users
Bob
Mary
Amy
Roy
Matt
Tess
Ross
BIEs - Business Contexts
Business Context→ BIE↓ | Human Resources | Agriculture | Construction | Entertainment | Notes |
---|---|---|---|---|---|
ProcessPurchaseOrder (instance #1) | |||||
ProcessPurchaseOrder (instance #2) | |||||
NotifyShipment (instance #1) | |||||
NotifyWIPStatus (instance #1) | |||||
NotifyWIPStatus (instance #2) |
Users - Roles
Role→Score role/tenant→ User↓ | HR Open Standards | ACME Brick | AgGateway | End User | Developer | Admin+Developer | Notes |
---|---|---|---|---|---|---|---|
Bob | |||||||
Mary | |||||||
Amy | |||||||
Roy | |||||||
Matt | |||||||
Tess | |||||||
Ross |
Business Contexts - Roles
Role→Score role/tenant→ Business Context↓ | HR Open Standards | ACME Brick | AgGateway | End User | Developer | Admin+Developer | Notes |
---|---|---|---|---|---|---|---|
Human Resources | |||||||
Agriculture | |||||||
Construction | |||||||
Entertainment |
...
Mary can access all BIEs because she is in the Score role Admin role. Administrator +Developer. Users in the Score roles Admin+Developer or Admin+End User can see everything.
Matt can only access BIEs in a business context associated with the ACME Brick roletenant.
Tess can only access BIEs in a business context associated with the AgGateway roletenant.
Ross can only access BIEs in a business context associated with the ACME Brick role tenant or the AgGateway roletenant, which in this example computes to be all of them.
Analysis about how this change could impact current on-prem users (and existing OAGi instances of Score), assuming we go with the business context (BC) approach
Actually current roles in Score are below.
Developer
Admin developer
End user
Admin end user
There is no difference b/w between being admin or not being admin in term of the BIEs Access. So, it is okay to simply refer to Developer and End User here. But these have to be differentiated in the authentication server.
When current instances of Score get upgraded to a multi-tenant version, roles have to be assigned to existing business contexts. Here are to options to keep the current accesses to existing BIEs
Assume Business contexts that BCs that have no roles assigned are accessible by any Score role or tenant.
Assume that Developer, Admin+Developer, End User, and Admin+End User can always access all BIEs even though these roles are not present in BCsassociated with business contexts.
All existing business contexts will be assigned all four roles when making upgrade to the multi-tenant version.
Apparently, approach (a) is simpler. And for convenience, we mighty assume (c) as well. I don’t see any issue with that at this point. It means that the current BIEs in OAGi instances will be accessible to all, but that can also be changed later on.
About the business contexts, currently anybody can manage business context. If the multi-tenant version restricts this to only Admin Developer or Developer, this can cause an issue with existing customers.
Alternatives are:
Make it an installation option to who can manage the BCs.
Make an inform decision with current users. Maybe this is a best practice to limit BC management to only Developer role.
Change the multi-tenant requirement to “Only Developer can manage BC/Role Assignment”. In other words, everyone is still free to create and manage the BC content itself but only Developer can assign roles to BCs. We have to think about BCs discard function, b/c right now anyone can discard BCs if there is no associated BIE - and this is likely still ok.
Option (iii) seems simplest.
So this seems quite manageable.
Analysis
...
between using Business Context & Role vs. using only Role to control BIE access
Using BC and Role | Using Role only |
---|---|
Pros | |
Offer multi-dimension control. I.e., can be made as if BIE accesses are managed by role alone. That is, a BC is created corresponding to each role and only that role. In this way, it is pretty much the same as using Role only. | |
Offer a level of aggregation to manage BIE Access rather than individual BIEs. | |
Cons | |
Have to always assign role to a BC, i.e., there is no role assignment automation. On the other hand, we can also implement a function to manage a default BC for a user account in the future. | Can automatically assign role selected by the current user to the BIE when it is created. |
Have to manage access for each BIE. |
...
Are all other user roles that are not Developer, Admin Developer, End User, and Admin End User considered subclasses of End User role? In other words, users in these roles inherit behavior of End User, e.g., they cannot create account, they cannot manage developer CCs, they can extend BIEs.
Note that if they can extend BIEs, it means that we have to also implement access logic on the CC side where they can manage only end user CCs. However, end user CCs have no BC assigned, so how to we infer access authorization? <serm>I couldn’t think of a nice and simple solution to this. The simplest thing to do, which sounds like a hack, is to do not allow BIE extension for users that are not End User or Admin End User. Another option is to inferred, roles associated with CCs from BIEs they are used in, but some EUCCs may not yet be used in any BIEs. Or we can say that if they are not used yet then only the owner can access it. </serm>. EUCCs logic also have to change in that only EUCCs with the same access authorizations can be used together, but what if the access authorizations change later on. This is getting pretty real complicated.
It looks like more sophisticated user role management functionality will need to be implemented in Score. For example, currently a user account cannot have multiple roles, e.g., an account cannot be both Developer and End User. We will still have to implement a user role management logic to do not allow the user account to have these two roles. Or that the user must select a role when he logs in, i.e., he cannot hold multiple roles when logging in. Also I think whether a CC or BIE is a Developer CC/BIE or End User CC/BIE, is inferred from the owner user. If the user can have multiple roles during the session, this logic can be affected.
...