I'm have a requirment consisting of 7 roles in my database, each role has different attributes and want to maintain a single login table with username, password and role. So, is it a good practice to maintain a same login table for group of roles and saving all the other related details of the each role in a separate table based on their roles.
Related
With the ability to allow secondary roles, is it a good practice to separate roles with 'usage' permissions on data warehouse compute from other roles which provide access to databases, schemas. tables? As example, I create a role called 'USE_DEV_DW". This role is granted usage to the DEV data warehouse compute. In parallel, I create a role that has usage on a specific set of databases and schemas. I then grant both roles to a user so that they can query the provided database tables using the separately provided compute (data warehouse). This way I can control what compute users have access to separate from what objects they can query. I don't see this being possible without the ability to provide for secondary roles? Looking to see if others have done something like this.
Even though there is no guidelines from Snowflake how to create the roles, the way you described makes sense.
When you have two layers of roles, let's call them database and functional,
it will be easier to create role hierarchies and assign them to users.
For illustration purposes assuming you have DEVELOPERS and ANALYSTS as your groups and you have SALES and PRODUCTS databases
You can create your roles and role hierarchies like this
Database Roles
R_DB_SALES_READ_WRITE
R_DB_SALES_READ
R_DB_PRODUCTS_READ_WRITE
R_DB_PRODUCTS_READ
Functional Roles
R_DEVELOPER
R_ANALYSTS
Role Hiercharchy
R_DEVELOPER
R_DB_SALES_READ_WRITE
R_DB_PRODUCTS_READ_WRITE
R_ANALYSTS
R_DB_SALES_READ
R_DB_PRODUCTS_READ
With this you only need to assign functional roles to users
SNOWFLAKE: Is it possible to grant a ROLE CREATE TEMPORARY TABLES but not PERMANENT tables?
The following snippet would not allow a role to CREATE TABLE, but allow CREATE TEMP tables. Also, the third command does not exist/work.
GRANT ALL PRIVILEGES ON SCHEMA myDB.mySchema TO ROLE myRole;
REVOKE CREATE TABLE ON SCHEMA myDB.mySchema FROM ROLE myRole;
GRANT CREATE **TEMPORARY** TABLE ON SCHEMA myDB.mySchema FROM ROLE myRole;
I can see many use cases where we want to limit a class of users from creating perm tables, but allow them to use scratch data.
That feature you are asking for is SNOW-62117 for reference, please ask about that with Snowflake Support.
Another option to consider for users to use scratch data is for an admin to create Views for scratch data.
https://docs.snowflake.net/manuals/sql-reference/sql/create-materialized-view.html
Or check out the data exchange to administer what types of scratch data you can use, depending on the use case. https://docs.snowflake.net/manuals/sql-reference/sql/create-materialized-view.html
Hope that helps!
Now I can use beeline to create role and user, every user have his/her own database using admin role to grant, but I need to create a new database that all users can create tables in the public database, how to create database like that?
Users can not create tables in other databases and can only create tables under their own databases.
You need an authorization provider that supports Hive. Apache Sentry is a popular one.
You will need to create a Sentry role that allows access to certain databases only.
Then assign a (Linux) group to that role.
Any user in above group will get access privileges to certain databases only (because of step 1.)
We are running single database for rest app server. We have three types of users
for customer
for administrator, and
for partners
Currently they have different tables and username and password are also in separate respectively Now We need to refactor this schema as user are expanding.
So should a single table User with Role table is OK ? (Here Role can be admin, partner or customer, manager).
OR
Should we a keep as it is as We will be having issue if we use User and Role table:
if an admin acquire a username then that username can not be the same again for customer or partner due to unique constraint.
I think user role can not be as "Customer" as customer is not a Role. Role can be admin, manager etc
I think this is not the right way to keep in single table. What are your suggestions?
I think you should create three tables for your user management, considering the fact that one user can have several roles (ex:- admin can also be a manager Or Customer can also be a partner). So User table and Role table have a Many-To-Many relationship. In order to create this relationship, you have to create 3rd table having userId and roleId as composite primary key.
additionally, i noticed that you are going to save user's passwords in the database. For the security reasons do not store passwords in plain-text. Instaed store the hash of the password using one way hashing algorithm.
You can read more about it from here -> Best way to store password in database
Yes, it would be better to keep separate tables because of the following reasons:
1. As you specified, Customer is not a role.
2. Since administrators would be limited in number, there is no point in fetching the record for authentication/authorisation from a large data set having the customers. It will hinder the performance.
User
id
userId
role (foreign key)
etc..
Role
id
name
etc
the above structure is best practice.
if you really need extra fields for admin, partner or customer
you can create separate entity for each one and you can refer user as a foreign key like as follows
Customer
id
name
user(foreign key)
etc
I am in database design development phase. Application will work with large number of users (LARGE :))
I designed 80% of database but I have one Users table which is connected to everything else:
Users {UserId, FirstName, LastName, Username, Password, PasswordQuestion, PasswordAnswer, Gender, RoleId, LastLoginDate etc etc}
I saw asp.net membership database structure where Users and Membership are two tables. My questions are:
Should I use one users table with all users data in it or more tables?
If answer is 'more tables', what tables to use? Any advice on how to structure relation between those tables?
This is sample relation that I have, and trying to improve. I don't understand why user and userChild are separated tables?
How many tables you need depends on your modeling needs.
For example if you include the RoleId in the Users table then you'll only be able to assign one role per user. Is that what you want?
Otherwise, if you have a separate table linking users to roles, you'll be able to assign more than one role per user.