I do not have much experience and I would like to know if there is an easy way to create user rights and privileges, so that each user can access only specific records from the database tables, based on the level he belongs to.
More specifically, suppose we have a group of companies where this group has some companies and these companies have some branches and the branches have some users.
I want the user belonging to the "group of companies" level to have access to and view all the entries in the database related to that group and what is below it (its companies and the branches of these companies).
The user who belongs to the "company" level should have access and see only the files of this company and the branches that this company may have in the database.
The user belonging to the "Branch" level should only be able to access and view this barnch records in the database.
And finally the user belonging to the "End User" level to have access and see only the records created by the user in the database.
Of course level "administrator" will have access to all records in the database.
I thought of creating a user table with a field "User_Level" and in each table to enter USER_ID where based on this I can find the level of a user but how can I restrict access based on the Group of Companies or the Company or the Branch where it belongs?
In APEX you can create authorization schemes to determine what components a user has access to within an application - but that is just a part of the answer to this question. Your question is about filtering the data that is showed to a user based on certain criteria.
There are a couple of possible solutions to this. Since this is a very broad question I'm just going to give you pointers/concepts to start your research. Up to you to determine what solution/combination is most suitable for your implementation.
Concept: Multi-Tenancy
If the data is used by multiple tenants then add a tenant_id to each table that has tenant specific data. In your case a tenant should be a branch. A simple design could be a groups table (to hold branch - companies - company groups), a group_members table (to define relationship between branch - companies - company groups OR between any group and a user) and a users table.
Concept: VPD This is a feature in the oracle database that allows a transparent implementation of security rules. In the application you'll define a simple select like
SELECT * FROM emp
But the VPD implementation will automatically add a where clause to the query to only show the records defined in the VPD policy. This makes developing the application a lot easier since there is less room for errors. Note that this database option could not be included for your licence. There is also something called "Poor Man's VPD" that does not use the VPD option. Google on how to implement this in your apex application.
Just do it all by hand: This is the least preferred option but it can be done. For every component where a select is done, manually add a where clause to restrict the returned rows. However this is very maintenance intensive and there is a ton of room for errors - obiously the data model will still have to support the striping of the data.
This blog post by Jeffrey Kemp might give you some pointers as well: https://jeffkemponoracle.com/2017/11/convert-an-apex-application-to-multi-tenant/ - go through the "further reading" section at the bottom.
you can create a procedure or function and in your app's shared components -> authorization scheme use that such as pl/sql function/procedure returning boolean and return true for the users you want to see the things and false for hiding.
In Apex components, select this authorization scheme like in items, pages etc.
I've been reading through all of the AppMaker documentation on security but there's one part that I can't wrap my head around which is how you limit access to only subsets of records.
Let's say I'm the Manager of a company and I want access to see Contract records for each Employee that I manage. I should have access to the Contract records that correspond to people I manage but not to those in other teams. I do need to have access to some contacts but not to all of them.
I can't seem to see how to do this in the interface. I had expected that it might be the case of creating a new Datasource which was filtered to only include the relevant records and setting access permissions on the new Datasource but Datasources don't seem to have any permissions assignable to them.
Is it possible to create access controls that limit access to subsets of data (from the server) or do you have to rely on hiding it in the client?
I had to make some assumptions in regards to your data setup, but here is my best attempt at answering your question. Most likely the Model Security setup should help you accomplish what you want to do, however to set this up you need to use the 'Advanced' option under model security. For your Contracts model set the 'Load' option to 'Owner or Roles', the field option you would need to choose is 'Advanced' and that will give you the option to set your field email to related models email field option. For this to work your Manager model needs to have a 'Manager Email' field.
Assumptions made:
3 models, Managers, Employees, and Contracts.
Managers model has an email field and Employees model has an email field.
Relations are as follows: Managers(one) - Employees(many) and Employees(one) - Contracts(many).
See the attached screenshots:
I am developing data application for governments, and I have a situation in which I need to make data shared to all users in one page but with different privileges levels that can control authorization based on locations, not just simple admins and viewers or editors roles.For Example, I have Locations Table that contains regions, cities, and districts in a hierarchal pattern, and all data will be displayed on the page will be affected by this location changes then the user who is authorized for a city can see only data related to this city and users can be authorized for multiple cities and multiple datasets within the page, If we maintained user inside a record then we need records number multiplied by authorized locations all multiplied by authorized datasets which can be infinity.So what's the best practice to store those user roles for each single data record related to specific location?
I'd have a look at row level security in the first instance. It allows you to set up security policies that allow different rows to be available to different groups/users.
Microsoft's thread for this starts here: https://learn.microsoft.com/en-us/sql/relational-databases/security/row-level-security
And there's also a good tutorial on Plural Site.
I'd post some examples but it's too broad a subject to answer here.
One point to note - there are performance limitations on row level security.
If security isn't as much of a concern then a mapping table and some clever joins is a popular way to go, and also much faster than row level security - depending on your data size.
I'm building a website that will be used by employees to log work that they've completed. The site contains a page to submit the information, a page to view the information and a page with the employees personal info like name, email, phone, etc. I'm using ASP.NET Membership for authentication. All code will be VB. My questions:
1) ASP.NET Membership only stores the username and email of members. I want to store additional information like first and last name, phone number, etc. Can I just update the tables in the membership database to include this information? Or should I store this information in a separate database? My goal is to populate text boxes on one of the pages with data specific to the user that is currently logged in.
2) The work completed will be stored in another database since it seems logical to keep it separate from membership data. What is the most efficient way to pull and display records from this separate "work" database that are specific to the user who has logged in and been authenticated against the member database?
3) I'm having trouble with the design of tables for the "work" database. Each record stored in the database will represent a days worth of work. However, a number of activities will occur during that day. Each activity will have a type of activity, location and amount of time worked. An employee can complete 1 activity or 100 activities. I assume I'm going to need a table just for the activities and then relate it to the work table. Does this sound correct?
For your first Point i will suggest you to create your own table of User and relate this table with membership user table with guid viz. keep on userid file in your table and relate it with membership table.
Second point will automatically get solved once you will create your own user table, all you need is to relate work and user table(created by you) to fetch the records from work
And at last if you are creating new table for activities how come you will relate it to your work table, again you will have multiple occurrence for record, instead i would suggest do not create another table for activities keep it in work table itself as if you are creating a new table, you will have to provide relationship with work which will result in redundancy.
Hope this helps.
I am planning to create a website using ASP.NET and SQL Server. However, my plan for the database design leaves me wondering if there is a better way.
The website will serve as a repository of information for various users. I figure I would have two databases, a Membership and Profile database.
The profile database would contain user data for all users, where each user may have ~20 tables. I would create the tables when the user account is created and generate a key used to name the tables. The tables are not directly related.
For Example a set of tables for two different users could look like:
User1 Tables - TransactionTable_Key1, AssetTable_Key1, ResearchTable_Key1 ....;
User2 Tables - TransactionTable_Key2, AssetTable_Key2, ResearchTable_Key2 ....;
The Key1, Key2 etc.. values would be retrieved based on the MembershipID data when the account was created. This could result in a very large number of tables over time. I'm not sure if this will limit scalability by setting up the database in this way. Any recommendations?
Edit: I should mention that some of these tables would contain 20k+ rows.
Realistically it sounds like you only really need one database for this.
From the way you worded your question, it sounds like you're trying to dynamically create tables for users as they create accounts. I wouldn't recommend this method.
What you want to do is create a master table that contains a primary key for each individual user. I'm assuming this is the Membership table. Then create the ~20 tables that you need for the profiles of these members. Every record, no matter the number of users that you have, will go into these tables. These 20 tables would need to have a foreign key pointing to the unique identifier of the Membership table.
When you want to query a Member for their user information, just select from the tables where the membership table's primary Id matches the foreign key in the profile tables.
This would result in only a few tables in the end and is easily maintainable and follows better database design.
Your ORM layer (EF, LINQ, DAL code) will hate having to deal with one set of tables per tenant. It is much better to have either one set of tables for all tenant in a single database, or a separate database per tenant. The later is only better if schema upgrade has to be vetted by tenant (like Salesforce.com has). If you can afford to upgrade all tenant to a new schema at once then there is no reason for database per tenant.
When you design a schema that hold multiple tenant the important things to remember are
don't use heaps, all tables must be clustered index
add the tenant ID as the leftmost key to every clustered
add the tenant ID as the leftmost key to every non-clustered index too
add the Left.tenantID = right.tenantID predicate to every join
add the table.TenantID = #currentTenantID to every query
These are fairly simple rules and if you obey them (with no exceptions) you will get a perfect partitioning per tenant of every query (no query will ever ever scan rows in a range of a different tenant) so you eliminate contention between tenants. To be more through, you can disable lock escalation to make sure no tenant escalates to block every other tenant.
This design also lends itself to table partitioning and to sharing the database for scale-out.
You definitely don't want to create a set of tables for each user, and you would want these only in one database. Even with SQL Server 2008's large capacity for tables (note really total objects in database), it would quickly become unmanageable. Your best bet is to use 20 tables, and separate them via a column into user areas. You might consider partitioning the tables by this user value, but that should be tested for performance reasons too.
Yes, since the tables only contain id, key, and value, why not make one single table?
Have the columns:
id, user ID, key, value
Put an Index on the user ID field.
A key idea behind a relational database is that the table structure does not change. You create a solid set of tables, and these are the "bones" of your application.
Cheers,
Daniel
Neal,
The solution really depends on your requirement. If security and data access are concern and you have only a handful of users, you can set up a different db for each user with access for him set to only his/her database.
Other wise, what Daniel Williams suggested is a good alternative where you have one DB and tables laid out with a indexed column partitioning the users data rows.
It's hard to tell from the summary, but it looks like you are designing for dynamic attribution by user. This design approach is called EAV (Entity-Attribute-Value) and consists of a simple base collection key (UserID, SiteID, ProductID...) and then rows consisting of name/value pairs. In a more complex version, categories are sometimes added as "super columns" to the tuple/row and provide sub-groupings for a set of name/value pairs.
Designing in this way moves responsibility for data type integrity, relational integrity and tuple integrity to the application layer.
The risk with doing this in a relational system involves the breaking of the tuple or row into a set of rows. Updates, deletes, missing values and the definition of a tuple are no longer easily accessible through human interaction. As your application evolves and the definition of a tuple changes, it becomes almost impossible to tell if a name/value pair is missing because it's part of an earlier-version tuple or because it was unintentionally deleted. Ad-hoc research as well becomes harder to manage as business analysts must keep an understanding of the virtual structure either in their heads or in documentation provided.
If you are looking to implement an EAV model, I would suggest you look at a non-relational solution (nosql) like MongoDB or CouchDB. These stores allow a developer to save and retrieve "documents" or json-formatted messages that are essentially made up of a collection of name/value pairs and can look very much like a serialized object. The advantage here is that you can store dynamic attribution without breaking your tuple. You always know that you have a complete tuple because you can store and retrieve it as a single "blob" of information that can be serialized and deserialized at-will. You can also update single attributes within the tuple, if that's a concern.
MongoDB also provides some database-like features such as multiple-attribute indexes, a query engine that is robust in comparison to other similar non-relational offerings and a sharding solution that is much less trouble than trying to do it with MySQL.
I hope this helps.