It looks like you are talking about design of security level related exclusively to your application system. It makes all technological problems irrelevant (or trivial); it all is the matter of adequate design.
I want to give you one general advice, something which would help you to avoid some very typical mistakes based on misunderstanding of the customer view of this.
Now, here is the idea: don't define those level the way you try to formulate. I'll explain why. By formulating and even by naming those levels,
you try to enforce some organizational structure in the organization of the customer. You need to understand:
this is your view of organizational structure, not the view of your users. Even if you think that your view reflects very typical really existing organization structure, and even if you are right in your understanding,
your user may not like it. Do you know what happens if the users start giving you new requirements? It's the best to avoid it.
Here is how you can resolve this. Ultimately, all permission come from some functional units of your application: some actions can be enabled or disabled. Usually, groups of action are logically related: if one thing is enabled, another one also should be enabled, but something else may not. So, instead of "levels", in some configuration UI, provide a set of check boxed (check boxes, not the list, not radio boxes), something like:
- Generate invoices
- Generate security confirmations
- View bills
- View invoices
- Confirm delivery
- Create records (specify what kind of records)
- Modify records…
- Delete records…
- …and so on
What to do next? Provide some action like "Create user role".
Here we are coming to a key moment: the customer administrator of the your system defines roles, not you.. The role structure should include 1) name of the role; 2) the subset of the actions listed above (the action list is your product, you decide how to group them); this subset defines what actions are permitted for the given role.
On next step, the administrator (again, someone on the customer side!) defines which roles are assigned to which user. Also, don't make a mistake here: you should provide an opportunity to assign more than one role to each users. You see, the "levels" are too inflexible. One worker may occasionally need to do the job of another one, without changing the profile. Again, the administrator on the customer side decides, not you.
Also, allow the customers to do their little mistakes. It could be a problem if some silly administrator creates a role when "create invoice" is permitted, but "view invoice" is not. Stupid? Yes, but not fatal.
Don't brain-wash your customers. Instead, allow them to make this mistake; it 1) will make your architecture more elegant and straightforward, 2) will not irritate the customer with error message which are hard to understand; 3) will let them understand the problem on like use case and easily fix it later. That is a better approach.
Now, let's look at the general, architectural data structure. If the work of each regular worker (not administrator) is those invoices and payments, the artifact of this work can be called
data. What is the assignment between the roles and personal records/accounts? This is a part of data which describes how data should be processed, so it could be called
meta-data, or, more exactly
meta¹-data. What is the data describing each role? This is the data describing meta¹-data, meta-data over meta-data, so it can be called "meta-data squared",
meta²-data. Finally, the whole part of architecture related to all those permission describes how meta²-data works, so it could be called
meta³-data. What are the artifacts of
meta³-data? The might not be described anywhere except documentation, so this level can be hard-coded. If all the roles and permissions are prescribed in some database, meta³-data will be reflected, among other things, in the database
schema.
I hope you understand how the related data structures could be defined, from either object-oriented or relational point of view, or both, but if you have some concerns, I'll gladly try to answer your follow-up questions.
—SA
Submit an article or tip