I'm part of a Facebook group for people who graduated from my high school. One of the members of the group keeps a running comment in which he posts the names and details of the former students who have died. You can look through the names, but it's not very easy to determine if a particular classmate is in the list. I thought of creating a database to hold that information but I wanted to limit access to people in the FB group. I wonder if it's possible to give access to group members through FB rather than manually adding each of them to the database access list.
I’m building a server for customers where each customer need to have each access to a database for serving his/her clients.
So my thought was to assign each customer to a specific bucket but just to find out now that a single couchbase only serve maximum of 10 buckets as recommended. But now, i don’t know if sharing a single bucket across my customers using their ID combining with the collection documents name they are creating as namespace in document type will affect the performance of all customers due to heavy operation by each customer clients on a single bucket.
I will also appreciate any database platform that can also handle this kind of project at large that performance of one customer will affect others.
If you expect the system to be heavily loaded, the activities of one user will affect the activities of another user whether they are sharing a single bucket or operating in separate buckets. There are only so many cycles to go around, so if one user is placing a heavy load on the system, the other users will definitely feel it. If you absolutely want the users completely isolated, you need to set up separate clusters for each of them.
If you are ok with the load from one user affecting the load from another, your plan for having users sharing a bucket by adding user ids to each document sounds workable. Just make sure you are using a separator that can not be part of the user id, so you can unambiguously separate the user id from the document id.
Also be aware that while Couchbase supports multiple buckets, it tends to run best with just one. Buckets are distinctly heavyweight structures.
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.
I have a web application and I want to control which user can see what data. So I thought a user can belong to a group (ie. DBA, Middleware specialist, UNIX guys, etc.) and the logged in user can only see its data in the app.
I want LDAP to do the authentication. I assume there aren't such groups specified in LDAP (ie. I don't want to use LDAP groups as I cannot force the company LDAP to create groups and put the users in those groups).
What I think of is a flexible solution like being able to use a custom attribute on each user (let's say named 'acces_groups') what the groups can be enlisted comma separated string.
I read that the schema of an objectClass (like organizationalPerson) has to be altered to do that. But is there an easy way to add such a custom attribute to a user in LDAP (I am talking about an already working company LDAP)?
Or how would you solve this (without disrupting/breaking the current LDAP)?
I didn't say what kind of LDAP (OpenLDAP, active Directory, etc.) for a reason as I'd want a common solution here.
These are two possible solutions/implementations :
What you supposed : You can add a schema and not alter the organizationalPerson objectClass. (Because altering an already established schema will make your LDAP not standart)
Then you add this objectClas to all your users to allow them to use the attributes defined by this schema.
You can define the acces_groups attribute and make it multi-value. You could also define one attribute per flag you need dba, middleware, etc. and make it a boolean, etc.
Why I would not do any this :
This is a much more complicated and intrusive way to do it than using built in mechanisms that are readily available in LDAP.
If your LDAP administrator allows youto modify your LDAP schemas like that, it should be no problem to ask him to use groups instead as this method is much less complicated and time consuming to implement
To manage it on daily basis is just a pain because you have no integrity mechanism. All the "CRUD" operations on the "emulated" group will have to be done "manually"
If you want to delete a group, you will have to delete the attribute on all the users who have it set.
If you want to list the "group", you will have to search all the users who have the attribute set with the correct value
etc.
Using groups : You can indeed create groups such as dba, middleware, etc. and assign the users to those groups.
It will allow you the use of group member ship and automatically populate an attribute in your user with the group which he is part of
It is LDAP standart and only need dealing with data than dealing with LDAP configurations (which involves downtime, possible errors/setbacks, etc.)
If your company allows you to modify the LDAP configuration AND the data of the users, then it should also allows you to create groups and assigning people to it
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.