Hi
I'm hoping that someone can help me. How would I extend role based security to deal with the scenario below? The user and roles tables are in a security database.
The scenario:
I have an application that a number of companies what to use. Where each company has a number of branches/offices.
Each table in the application has a CompanyID and BranchID to isolate each companies data.
Each Company wants to be capable of administering users/roles for the whole company and to be able to run reports for the company as a whole, or one or more branches.
Branches are responsible for maintaining users/roles for their own branch only. And users can only see data for their own branch.
Any help would be gratefully appreciated.
My guess is that you don't need to extend/alter the role-based authorization at all - just use it as-is.
Instead, what you can do is put the Company/Branch values into either your custom identity class or into ApplicationContext.ClientContext. Either way those values automatically become globally available to all client- and server-side code.
The important part is that they are available to your server-side code, and in particular to your data access code. This means your data access code can always apply these values as a filter to any WHERE clause, ensuring that the current user only ever sees the values for their Company/Branch.
The role-based authorization can then work as normal, restricting what the user can do or see within the data they are able to retrieve, but they'll never even have access to, or be aware of, any data outside their realm.
Thanks Rocky. I should have thought of that myself, but I have too much to do and so little time.
EDIT:
I just wanted to clarify your suggestion 'put the Company/Branch values into either your custom identity'. To me this suggests that Company/Branch values be columns in the user table and then returned using the Logon stored proc, is this correct?
Copyright (c) Marimer LLC