Designing Role/User based application security

Question

I am sure this has been done by many of you and was looking for some guidance into designing a robust, scalable, application that can handle data (row level) security for multiple users.

We are looking at a system whereby users, some acting as individuals, and some as part of larger groups will need access to both their own data as well as to data shared with them by other individuals and organizations. In some cases the data is shared just to view and in other cases full edit permissions will be available. And even within the same organization there will need to be restrictions on what users can see in terms of data created by other users in the organization.

So a very rough example may be... User A with Role X, (individual user) User B with Role Y (individual user) User C with Role Z (individual user) Users D and E with Roles X, in Organization AA Users F and G with Roles Y in Organization AA

Each individual User might create for eg a contract on our system. That contract shoudl not be viewable by anyone else until they choose to share that contract with other individual users eg A will share his contract with User B or F. But User A may also want to share his contract with all users of Role Y in Organization AA. Likewise sharing the contract may even mean permission to edit the contract.

We initially had wanted to have a separate schema for each individual user to ensure security at a data level but this makes sharing more complicated and also may result in 1000's of schemas (which just doent seem like a good idea). So it seems like our only resort is to leave all the data in one schema in one db and simply design a user and role driven application level security model which can accommodate all the required CRUD permissions on each contract. It just sounds like this is going to get very complicated and "not so pretty". For every contract we would have to define a list of users and roles by organization which with the individual permissions for each one of these users/roles. Has anyone done anything like this? Any suggestions with regards to a good and secure application design?

Thanks

Answer 1

Here are some rough thoughts for this requirement

Since you are talking about data security control rather than system function/feature access control, so I will focus on data access control here.

Structure of Access Control Classes

• You might want to treat all level of security atom as the same thing, e. g, it's generally defined in a way that individual / permission / role / group are inherited from the same basic principle class, and then conceptually, all access control definition will be on this basic principle, hence you don't need to know whether the control is over a role, a group or a user, this will give you more flexibility and simples the question.

• You might also want to define the principles as kind of combination / hierarchy structure, for example

  • User A is assigned RoleA, RoleB, RoleC and PERMISSION2
  • Role A is a combination of RoleC and RoleD
  • RoleC is a combination of permission PERMISSION1, PERMISSION2 etc.

BTW: Since the design here is very flexible so you will need a system level conflict check mechanism to check

• The conflict between all the principles upon any assignment to make sure there's no system level conflict(for example, roleA defines that the user can not update document of Type A, while PERMISSION2 defines it can), another possible method is to define a priority for different type of principle, for example, defined level USER > ROLE > PERMISSION.

• And also a function level(SOX law etc) conflict check to make sure there's no function level conflict, for example, someone capable to do payment can not have access to operate on cash etc)

Access for Documents

• Then a schema such as document / principle / restrict type / restrict operation / restrict start and thru date could be defined to store data access control for each document,

  • Document could be a contract, a purchase order, purchase request etc, it's actual type doesn't matter at all here.
  • Principle could be a user / permission / role / group etc, also you don't want to focus on the actual principle type here, by this design, only one row of data is needed for those normal documents(since we could define it on role level), and also if the user choose to share this document with a particular organization or individual, it will also be able to handle.
  • Restrict type might be "ALLOW" / "NOT_ALLOW" etc,
  • Restrict operation could be "VIEW" / "UPDATE" / "ADMIN" etc,
  • Restrict start and thru date will be the date range this access control take effectives, by combine this thru date, operation and restrict type we defined, you can combine exceptional access control with normal access control, hence to implement requirements like share / delegation will be easier, and it also didn't bring too much complicate for normal access control.

Organizations

If your organization has a hierarchy structure, you can also define how the access control to be inherited for parent and to child organizations, a sample schema might be,

Organization Id / Acccess inherent Type / Start and thru date.

• Organization id: primary key of this organization
• Access inherent type: Could be something like: ALLOW_ALL_CHILD / ALLOW_ALL_PARENT / ALLOW_ALL_SAME_LEVEL /DENY_ALL etc.
• Start and thru date could be the date this role takes effective and ends.

Something you might be able to implement could be:

• For organization A, all it's subsidiaries is not allowed to view / update any documents under it.
• For organization B, all it's subsidiaries is allowed to have view / update permissions to all documents under it, but not to the documents on the same hierarchy level.

Then you can combine this organization level access control and the document level access control, when evaluating the rules, the document level access control always have a higher priority than organization level ones.