I'm modelling a database schema that has the requirement of including multi-user account functionality:
A multiple user account enables multiple users to login to the same
account in order to do the job according to their permission level.
This means that it is possible to maintain a single account for your
entire marketing team. The account owner can add as many users as
he/she wants and limit what permissions each of them has. You can
choose a role for each user: account manager, marketing executive,
marketing assistant, etc… or create a customized permission.
At the moment I have one users table that stores the information of a generic user with the username and password etc. How would one implement a multi-user account functionality? Could an extra field be added to the users table that simply indicates the role? Would a separate table be required? I would like to use the principle of keeping this simple where possible but don't know how to approach this.
Each user is a assigned to one group, is that correct? In that case, the user table can have a groupid which is a foreign key to a user_group table which lists all the access roles that you have.
Now the group (groupid) may have a number of "access rights" of what they can (or cannot) do on the system, which can be defined by you. You can refer to this as a default set of access rights.
If you want to create a customized permission, it's best to read this SO question / the first two answers in the least:
Best Practice for Designing User Roles and Permission System?
In the second example which discusses bitwise operators (if you are doing this custom, without help of a framework as discussed in the first answer), this is interesting assuming you understand the concept. Effectively you are summing up the decimal integers but they are being compared in binary to know what roles are granted for a given user. You can use this concept to also define what access rights each preset groupid has for predefined roles.
For Oracle we have "Virtual Private Database". For SQL Server / Azure we have "Row Level Security". Whichever RDBMS you are using, check for similar feature. It is most efficient for this scenario.
Related
The questions are related to snowflake account with organization/ orgadmin role enabled.
1.Is it possible to detach a snowflake account from a snowflake
organization?
a. If yes, will the removed account become a standalone(separate contract)
account? How does the billing work?
b. Will the account url change after detachment?
c. Procedure to achieve the above?
In an organization, are the background services charged on each account?
Can we clone a database across accounts within an organization?
What happens to the other accounts within an organization when the
primary account is deleted?
Can we get a cost comparison table between 2 standalone accounts and an
organization with 2
accounts?
After detachment can the account type/region/cloud provider be changed?
I have asked similar questions to snowflake support through support ticket system, But would like to get answers from the community too.
P.S If I get an answer from Snowflake, I will post it here!.
Yes - but you'd need to contact Snowflake support to do that.
a) not sure what you mean by standalone. All accounts are technically standalone. If you mean from a Snowflake contract, perspective, if you want them to be on a separate contract, you can do that. If you don't, it can remain on the same contract.
b) see (a).
c) if you are using the URL that uses ORG and account name, then yes, the URL will change. If you are using the URL that leverages an account locator and the deployment/region, then no. If won't and can't change.
d) Call Support
background services are always related to an account. An organization is just a way of grouping accounts.
No, but you can replicate data from one account to another account in Org. Cloning can only ever be done within a single account.
What happens to what? If this was related to cloning, then I don't think the question is valid. A replication would cease to replicate.
No costs for Organization so costs are the same per credit and per TB costs that you'd see on any account.
No, you can't move an account around. You'd need to create a new account, move your objects to the new account and then just remove your original account, if you wanted to move platform or region.
I'm creating a book rental application using Express and Postgres. One feature I want to include in the app is an admin user that will be able to add books and perform other tasks that a 'normal' user cannot. I have created a 'user_account' table in Postgres with one field being a 'user_role'. Since I only want there to be one admin user I don't think I'm going about this the right way. I need suggestions on how to handle this issue. Is the 'user_role' field even necessary for the user table?
Since I only want there to be one admin user I
That is a weird thing to design your application around. Why not just make it possible for any number of people to be administrators, but then only assign the role to one person? You could even use a partial unique index to enforce that constraint, if you wanted.
I have an ASP.NET MVC + SQL Server application with 250 simultaneous users daily which uses AD/NTLM SSO to do all the authorization using a custom authorization security class that control access to controllers & Actions based on users & groups.
A dilemma recently came up where the 50K+ account records of the database are going to be managed by different groups to varying degree's:
All users will be able to view most records certain records can only
be edited by certain users/groups of specific departments There will
be an admin & support groups that will be able to edit any group owned records
etc.
This is not a problem of who has access to what features/forms/etc. in the controllers, but instead a dilemma of data ownership restrictions that must be imposed. I am guessing this means I need some additional layer of security for row level security.
I am looking for a pragmatic & robust way to tackle data ownership within the current application framework with minimal performance hits since it is likely the same thing will need to be imposed on other much larger tables of data. Initially there will be about 5 ownership groups, but creeping up to 25 to 100 in the near future.
Sadly there are no cut and dry business rules that are hard and fast that can be implemented here.. there is no rhyme or reason make sense of who owns what except the record primary key id.
To try to fix it I was thinking of creating a table of owner_roles and map it to the users table then create another table called accounts_ownership that looks something like:
tbl(PK),row(PK),owner(PK),view,create,modify,delete
accounts,1,hr,1,1,1,1
accounts,1,it,1,0,0,0
accounts,2,hr,1,1,1,1
accounts,2,it,1,1,1,1
accounts,3,it,1,0,0,0
But in doing so that would create a table that was 250K lines and could easily get some crappy performance. Looking at sites like Facebook and others this must be a common thing that has to be implemented, but I am hesitant to introduce a table like that since it could create serious performance issues.
The other way I thought this may be implemented is by adding an extra column to the accounts table that is a compound field that is comma separated that would contain the owner(s) with a coded set of rights ie.:
id owners
1 ,hr,
2 ,hr,
3 ,hr,it,
4 ,it,
And then add a custom class to search using the 'like' statement.. provided the logged in users role was "it" and the comma's were reserved and not allowed in owners names:
SELECT * FROM accounts WHERE owners LIKE '%,it,%'
... however this really just feels wrong from a DBA perspective (ugly as hell) and a maintenance nightmare.
Any practical approaches on how I could implement this without destroying my site?
Start with Role-based access control, you can possibly skip the roles from the pure definition but should be able to implement it like this:
Every user can be in one or more groups like admin, support, it, hr
Every data row has an owner like it, hr
On Access, check the access: an admin can see and edit all rows. Support+it sees every row and can edit those from it etc. This way you need only (user-groups + row-access) new rows in your database, not (user-groups * row-access).
User groups in your scenario should be possible to hardcode in your application, in a CMS there is generally a table defining what rights to assign to each user group - complicating the coding but very flexible.
Roles in the original concept allow a user to select what rights he/she wants to use, there would be a "Unlock with admin rights" or the like in your interface.
Primarily for performance reasons, I went with the less elegant approach listed. It took some doing, but there are careful application controls that had to be created to enforce things like no comma's in the id's.
I'm certainly no DBA and only a beginner when it comes to software development, so any help is appreciated. What is the most secure structure for storing the data from multiple parties in one database? For instance if three people have access to the same tables, I want to make sure that each person can only see their data. Is it best to create a unique ID for each person and store that along with the data then query based on that ID? Are there other considerations I should take into account as well?
You are on the right track, but mapping the USER ID into the table is probably not what you want, because in practice many users have access to the corporations data. In those cases you would store "CorpID" as a column, or more generically "ContextID". But yes, to limit access to data, each row should be able to convey who the data is for, either directly (the row actually contains a reference to CorpID, UserID, ContextID or the like) or it can be inferred by joining to other tables that reference the qualifier.
In practice, these rules are enforced by a middle tier that queries the database, providing the user context in some way so that only the correct records are selected out of the database and ultimately presented to the user.
...three people have access to the same tables...
If these persons can query the tables directly through some query tool like toad then we have a serious problem. if not, that is like they access through some middle tier/service layer or so then #wagregg's solution above holds.
coming to the case when they have direct access rights then one approach is:
create database level user accounts for each of the users.
have another table with row level grant information. say your_table has a primary key column MY_PK_COL then the structure of the GRANTS_TABLE table would be like {USER_ID; MY_PK_COL} with MY_PK_COL a foreign key to your_table.
Remove all privileges of concerned users from your_table
Create a view. SELECT * FROM your_table WHERE user_id=getCurrentUserID();
give your users SELECT/INSERT/UPDATE rights on this view.
Most of the database systems (MySQL, Oracle, SQLServer) provide way to get current logged user. (the one used in the connection string). They also provide ways to restrict access to certain tables. now for your users the view will behave as a normal table. they will never know the difference.
a problem happens when there are too many users. provisioning a database level uer account to every one of them may turn difficult. but then DBMS like MsSQLServer can use windows authentication, there by reducing the user/creation problem.
In most of the scenarios the filter at middle tier approach is the best way. but there are times when security is paramount. Also a bug in the middle tier may allow malicious users to bypass the security. SQL injection is one thing to name. then you have to do what you have to do.
It sounds like you're talking about a multi-tenant architecture, but I can't tell for sure.
This SO answer has a summary of the issues, and links to an online article containing details about the trade-offs.
I am implementing an authentication system into an existing database system. Currently, the database has a "Person" table that includes things like: First Name, Last Name, Date of Birth, Email (username), etc. This is the primary table for a user.
I need to add the following fields for authentication: Password, IsLocked, LockDate, LastLoginDate.
Would you suggest putting these fields in the Person table or would you put them in a new Authentication table? My original plan was for "Person" to simply contain data about that person, not necessarily about authentication.
The other approach could be to store the password along with the email in Person, but then place the authentication data in a separate table. This way, the username and password would be in the same place, but the meta data would be in its own entity.
Anyone have any thoughts?
Thanks for the help!
Keep them separate so that users can query the system for information about a Person without necessarily having access to their account credentials.
This also has a nice side-effect where not all Person entities may have accounts.
Keep the account information separate. Your current business requirement may be for each person to have only one account, but it could come up in the future that a person needs to have multiple accounts, or even that you need an account that is shared by multiple people. Having a separate table for authentication means that such future changes will have a smaller impact on your code.
Also, from the perspective of protecting authentication information, the fewer people/processes that can access the account data the better off you'll be. It's much easier to implement table-level access than column-level access.
I don't think it makes much sense to create a seperate table for Authentication data. Authentication can't exist independently of the Person, as far as I can tell - and there doesn't seem to be a way one Person could reasonably be associated with two Authentications (or vice versa).
In other words: There's a 1:1 relationship between Person and Authentication, so why split it off?