I'm thinking of writing a CouchDB-backed application that will store sensitive data. Is it possible to set things up so that I can get something like MySQL's and PostgreSQL's access control, where particular users on the system (users in the sense of Unix system users) can be denied or granted access to a particular CouchDB database?
Absolutely, you can set up users in the _users database. You can assign roles, groups, as well as any other custom fields for each user. In the validate_doc_update function in your design document(s), you can check user roles and approve or deny access based on that. You can also globally assign users as "readers" and "writers". You can authenticate users via Basic HTTP Authentication, OAuth and a variety of other methods.
Refer to the Security Features Overview and Document Update Validation pages on the wiki to get started.
Related
If I have a database "Movies" and I have 3 different users I created using the
Create User... identified by ... "
command. Users are "A" "B" "C" with different roles, and a table inside this database called "users" where I save username and password.
Can I use these MySQL user accounts (A, B or C) in the web application "login.php" since they are not saved in the table "users".
There are several types of user in most web applications.
The easiest to explain are "application users" - when you sign up for Facebook, or Github, or Amazon, or indeed Stack Overflow, you create an application user profile. This profile can have all sorts of attributes, and may have rights within the application - for instance, on Stack Overflow, some people have rights to edit questions. These rights apply to application domain concerns (like "question" in Stack Overflow).
The other type of user is "infrastructure user" - the credentials used to authenticate and authorize applications in the infrastructure that runs your application. These users have rights at the infrastructure level - in your database, those rights may include select, insert, create table etc.
Its almost never a good idea to have your application users mixed with your infrastructure users. You almost certainly don't want someone logging into your web application who can drop your database.
If you really need to do this, you have to modify your connection string, and log in as the infrastructure-level user.
I'm planning a multi tenancy app with nodejs and sequelize(mysql dialect). I'm gonna have a single app and multiple databases for each client. I'd need to connect to a client database after authentication (with passport.js). So there is a classic master database with clients info and db user,host and pwd, and then after the successful login the app connects to the specific client db. How could i do something like this? I was thinking to use sessions...maybe a middleware that for each request fetch the session and then passes the data to sequelize config object? Could anyone share with me how he/she manage to do something similar? I'm stuck in a logical trap ! Thank you
You're very close.
When you look up the user in your master db, in order to validate the username/password, you will also look up the connection string to the user-specific database. Then youu can create a simple express middleware function to open up the specific connection at the beginning of each request.
You will need usernames and passwords for the databases. For best security, they should not be the same as the users' usernames and passwords: If somebody cracks your web app and user table, you don't want them to have all the passwords.
But, what you propose is not classic multitenancy. Multitenancy is creating a single database, in which the various tables have columns mentioning which user they are for. Then once passport tells you the user's id, you can put it into your queries (for example, SELECT .... WHERE user_id = <<value>> AND ....
Your proposal will work tolerably well for a few dozen users. But what happens if you get tens of thousands of users? That will be a lot of separate databases.
I'm working on a SaaS product and trying to figure out the best way to design the database for my scenario, which I think is pretty standard.
I should not that I don't have an experience designing such a database.
I tired researched online, but there isn't really any info I could find about implementation. There are quite a few comparing the different multi-tenant architectures.
For the multi-tenant approach, I decided go with a single database - seemed to be the most fitting.
Here's the basic list of what should be supported:
Multiple clients, all separated, no sharing of data between them.
Each client has it's own user base (staff/employees).
The client's staff members have different access levels to the system (exposure to different areas, ability to perform certain actions)
Each client have it's own customers.
I can wrap my head around the basic concept of having the tenant_id on any table belongs to that tenant. I guess my issue is more with how to combine it with different access levels per client's staff member.
How would you go about it?
Any reference some implementation of such a DB?
Thanks
Update
After #dmfy answer, I gave it some thought and came up with this solution:
account
-id
-name
user
-id
-account_id
-username
-password
role
-id
-account_id
-name
user_role
-user_id
-role_id
access
-id
-role_id
-name
role_access
-role_id
-access_id
session
-account_id
-user_id
-token
I'll explain-
The role table is essentially a "group" of users associated with a list of permissions/access levels.
The access table represents a single permission. An area of the platform, an action that can (or cannot) be performed.
A row in the session table is created after a successful login. Each time there's a call to the server, if the user has been verified against the token, I will lookup the roles for that user (using the session.user_id on the user_roles and collect it's access list using role.id on role_access.role_id).
Once I have the access list I can check against the request and see if the user is permitted to perform the action.
Notes
role can be customized for each tenant/account (e.g one can have "Management" and "Employees" and another can have "Management", "Support", and "Sales" ), hence the association with account.
access on the other hand, is platform-wide. The platform have the same set of areas and actions across all tenants. So there is not need to associate it with a specific account.
An improvement to the access lookup could be to store the access list on the session on login, to eliminate the double join (get all the user's roles, get all the roles' access lists).
Questions
Firstly, what is your overall opinion on the design. Do you see any flaws?
Is saving the account_id on the session really needed/a good idea?
Is having the server check whether the user has access to a certain resource is the standard way of doing this? Is there a way to do this as part of the itself query (e.g get an error from the DB itself)?
You might get a better answer by describing the requirements before you outline the solution.
Your design seems to describe an authorisation scheme. It looks fairly credible - I'd summarize it in natural language as:
A tenant is an account.
An account has many users.
A user can have
many roles.
Roles grant access to many permissions.
The system
maintains a list of sessions, mapping requests to users; this in turn
allows the system to check whether the user has permissions for a
given action.
Without knowing your requirements, that seems fairly reasonable. You may want to include a link from "account" to something your application recognizes as "tenant".
The big question is how you will use this data in your application. Checking permissions - especially fine-grained permissions - for each request could be expensive.
The specific solution here depends heavily on your application framework - many have built-in authentication/authorization models, and it's usually a good idea to use those built-in features.
For ideas on how to implement this, you could look at CanCanCan, an authorization framework for Ruby on Rails, or Authority for Laravel.
It's also not clear how the actual data in your system will be linked to an account - if your system tracks widgets, does the "widgets" table have an "account_id" column? If so, how does your application track who is and is not allowed to access that row?
It sounds like you're conflating database users with application users. In a SaaS product with a shared-schema model, individual users won't have direct acess to the database; instead, your application connects as a single user with appropriate rights on all objects it needs. What you're worried about is what areas of the application users can access and what actions they can take. This means you need to build your authorization model into your schema.
The simplest possible model has two levels of access: regular users and administrators. This can be represented with a users table having a tenant_id to associate individual logins with the correct client, and an is_admin flag. Your application then ensures that only users with the flag set can access administrative functionality. If your authorization model is more complex, design your schema appropriately (users may have a many:many relationship with roles, for example).
Note also that a tenant_id column is only strictly required for tables directly related to tenants; if you have a profiles table with a user_id, you can trace the relationship back to the tenant through users. In some cases it may make sense to add the tenant_id to avoid long join chains.
I read about GT.M security docs and see that GT.M do not include a specific security solution ,it depend on OS system user roles
Now I want that each user have specific roles on databases ,how can I do that
Example :
user 'manager' can act SET ,KILL command on global "Account","Salary"
user 'employee' just only can act ZWRITE command on global "Salary"
Assume that "Account" and "Salary" global variables are mapping in the same database file
Thanks,
GT.M does not implement a security layer itself, and instead uses on access control as implemented by the operating system (user/group/world permissions and layered security such as SELinux). I know that some applications have accomplished what you want using the traditional user/group/world controls, but it does require the application schema to be amenable. Other applications implement access controls at the application layer.
The quote above by #DAiMor is dated. The current quote from the manual is:
Ensure that database file ownership (user and group), UNIX user and group ids, and permissions at the UNIX level match the intended access. If finer grained access controls than those provided by user and group ids and permissions are needed, consider using, where appropriate and available, security products layered on top of the operating system.
In general, we no longer recommend Access Control Lists. I notice that there is a later mention of it in the manual, which we should remove. ACLs work for files, but not for resources like shared memory.
Here I see, that you are talking about read and write access, so, you have to change access to DB file, you can add your users who should have an access to write to UNIX group with such access.
Quote from GT.M Security Philosophy
Ensure that database file ownership (user and group), UNIX user and group ids, and permissions at the UNIX level match the intended access. If finer grained access controls than those provided by user and group ids and permissions are needed, consider using Access Control Lists (ACLs) where they are available.
I would like to create a MySQL user with permissions to create and remove other users, but prevent my own (superuser) account from being deleted or modified.
The user seems to need CREATE USER to be able to manage users, and this seems to allow deletion of all accounts.
Goal is to provide MySQL as a service with the possibility to do some user management, while keeping an administrative user on the database protected from users.
Edit: Users will be connecting to MySQL directly using the CLI mysql client or a third party database tool. Of course this problem could be eliminated by providing the user a custom system to do user management and do custom access control in there, but I'd prefer to give direct access to the DB.
MySQL does not provide this level of control over user management. But I can imagine a small application of your own that would let your authorised users to manage only users you allow.
Only the application would connect to the database as a privileged user.
Only the application would issue the actual CREATE USER and DROP USER statements, and only on accounts that you allow.
Having manipulated these actual MySQL system users via this application, these accounts would become available for direct connection.