Entity Framework : Relational Model help for Permissions, Users etc

Question

Can anyone help?

I am looking to create a good relational model for managing Permissions.

I currently have a Users table, and various other tables like Customers, Suppliers.

The user needs permissions to View, Edit, Create in either Customers, Suppliers.

I will use these tables in EF to decide what access a user has and weather to show a form or not etc.

My original model goes like this, although i think its wrong, as it dosn't state anything about Permissions.

Users UsersCustomers (contains relation between Users and Customers) UsersSuppliers (contains relation between Users and Suppliers) Customers (customer table) Suppliers (suppliers table).

Although this works, i.e. it relates a user to a Customer for example... It just doesn't seem right.

I was thinking of putting a intermediate table called Permissions which woul have a Id and a UserId that would link the user table. Then i could link Permissions to a table like

PermissionsCustomers (in place of UsersCustomers) that would contain a relation between the persmission and customers.

I think this where i am not quite getting an optimum design. Once this design is correct it would be also missing a table to assign what type of permission a user has to a Customer i.e. Edit, Create or only view etc.

I would love to hear some feedback or an example of a strong model that exists that functions like this.

With regards to the customers, suppliers, these are just 2 examples, there will be lots more tables like deliveryLocation, accountsLedger etc.

It would be great if i could do a query that said "Show me all permissions that user X has", currently with my setup i would have to query each Intermediate table separately.

I would be using this via an ORM like entity framework.

A little lost with the structure of the relational model.

Thanks in advance.

Answer 1

Given that you will have a very small number of customers and suppliers (20 total), you don't need a very complicated system.

What I have done in similar situations is have a permissions table setup with a structure like this:

• UserId (the users id )
• RoleId (an id that links to a role table, with things like "Edit Customer", Delete Supplier", view customer etc. )
• ObjectId (this would be the id that identifies whatever object you want to secure, so either the supplier id or customer id.)

The role table would have:

• Id (unique id relates to RoleId in the permissions table)
• Name (unique name of the role, i.e. 'Edit Customer')

Then each user entity is linked to a table of permissions, each user has multiple permissions. When a user logs in, I generally would choose to load all their permissions into an in memory list, so a user would have a list of permissions. The permissions list would have just the ObjectId, and the RoleName and/or RoleId (I tend to use rolename to make the code easier to read as you can see below in the example)

protected bool HasPermission(long ObjectId, string RoleName)
{

//Users in the Administrator role have access to everything in the system.
if (this.IsAdministrator) {
    HasPermission = true;
    return;
}

foreach (Permission P in Permissions) {
    if (P.ObjectID == ObjectID & P.RoleName == Role) {
        HasPermission = true;
        return;
    }
}
return false;

}

then, if I want to know if a user as permission to something I would do this:

if (myUser.HasPermission(CustomerId, "Edit Customer") {
  //allow the user to edit the customer
else
  //allow the user to only view the customer (for example)

or

    if (myUser.HasPermission(SupplierId, "Print Supplier") {
  //allow the user to print the record
else
  //give user a warning

The key is, that each 'role' needs to be unique, you can't have a generic 'Edit' role, because if you have a customer and supplier that have the same id, and you want to see if the user has permission to 'Edit', you may get the wrong result. So have a role called 'Edit Customer' and another role called 'Edit Supplier'.

This solution wouldn't scale well imo, but for a database with just dozens of records that need to be secured, it works just fine and is simple to implement and maintain. It is also not setup in a truly relational way, i.e. the ObjectId in the permissions table is not related back to either the supplier or customer table.

(Also, in this scenario I my user object knows if it is an administrator or not, administrators don't need permissions setup, the have access to everything, so no permissions search is needed - saves a few nanoseconds of time)