Is there any way to get row-level security in SQL Server 2014?
My problem is:
I have a table with data for multiple regions
I created a view for each region
Specific user will have access to specific region views
But without giving access to the underlying table, those users are unable to access the views
I need to restrict users to view only certain rows. Are there any possibilities to do so?
I have achieved it by creating views for the specified rows and giving permission to only views not underlying table
so user has visible to only rows which are returned by views. We can control rows to be returned by where clause in view.
but table may contain other rows as well
key terms : Ownership chaining
The same SQL query returns results based on identity. No special database code required. You can control how the rows and columns return, and even aggregation. For example, the SQL below will return different results for managers, analysts, and developers.
select * from employee_salaries;
Related
I want to query in ssms but I always have to add the specific schema as a prefix, although I have ran the query:
USE (the specific db I wanna use);
GO
What should I do for ssms to bring back only tables from the specific db and schemas while querying?
Within SQL Server, you use the Fully Qualified Name. That consists of three parts (though technically, when using a linked server, you could add a servername part as well):
Database
Schema
Table
And can be used in the following manner:
SELECT * FROM <database>.<schema>.<table>
The USE keyword simply changes the context in which you are executing a SQL command. It's identical to using the drop-down box in SSMS to change to a different database.
By switching the database context, you can typically skip the part of the query above. By switching context, it is assumed all commands will be executed within the database you changed to.
The reason it's still there is if you want to access objects that physically reside within a different database on the same SQL Server instance.
The schema is just a way to group your tables. The default schema is database owner (dbo). If you omit the schema name, it's assumed the object is in the dbo schema. So the following 2 commands are assumed to be identical:
SELECT * FROM dbo.MyTable
SELECT * FROM MyTable
However, using schemas is a great way to structure your database, as you can logically group related objects within the same schema, and assign permissions accordingly.
From an OLTP perspective, you could have a schema dealing with orders, and one with sales. That way it is easier for people to filter only the objects they are interested in, and for the dba to limit access to schemas to specific departments.
If you work with data warehousing, it's not unusual to see an Extract schema, a Stage schema, and a Fact and Dimension schema.
I have created a series of views that operate on a fairly large table. The table has been properly indexed and the performance is entirely sufficient. I would like to add an additional layer of views to the DB that are effectively views of views. What I want to know is whether SQL Server is smart enough to use the indexes on the underlying table when it builds the query, or whether I need to index the first tier of views somehow?
Yes it is. A view (not persisted) is nothing more than a query stored on your DB. If you have a view called view1 as select * from table1 and do select * from view1, SQL Server will automatically transform that to select * from table1 and then build a execution plan
Same rule applies if you increase the chain of objects adding more views.
Now in SQL views are tables which can be used for data abstraction (showing specific data to required users).
Also you can edit data and insert data into the original table through views. What I want is an equivalent of this in access.
I have been able to create a view table in access but the problem is that it cannot be used to update the record set.
In Jet databases, the equivalent of a view is a saved query. You should be able to update the base tables through the query, provided that the query obeys certain rules. These rules are documented in the Access 2007 help. If you provide your view definition and some details about the base table(s), we can give some specific advice about why the query isn't updatable.
If you had different roles on a website perhaps, user, developer, admin, maybe moderators user levels.
How would a database view help? Whats the difference between querying the base table and the view table?
View is just a stored select query for popular scenario allowing execution time optimization. View is just faster than query.
Of course you can prepare special views for your website roles, and query views instead of tables to show filtered or aggregated data.
View can refer to many tables. Thus, instead of granting permissions for each table individually you can give permissions for the view. Also, underlying data in views is readonly (by default; some servers let you create editable views), as name VIEW implies. Usually(not always!) querying views is faster than querying tables.
I have a stored procedure that updates data in a table for a specific record. I have several users who will be making use of this stored procedure however I only want to them to be able to update records that are assigned to them.
Each record that is to be updated by the stored procedure has a field named "UserID" which define who has control over the record. I also have a mapping table that maps active directory logins to the UserID's.
I am using Active Directory so SQL Server knows who is attempting to execute the stored procedure. Is there a way within the stored procedure to look-up the users active directory login in another table and then determine if they have access to the records attempting to be updated?
You can find out who the current user is in the proc by calling SYSTEM_USER and incorporating that into the query that updates the rows.
Does this article help? Granting Row-Level Permissions in SQL Server
It recommends the following steps
Create the table, adding an additional column to store the name.
Create a view that has a WHERE clause based on the user name column. This will restrict the rows returned to those with the specified value. Use one of the built-in functions to specify a database user or login name. This eliminates the need to create different views for different users.
Create stored procedures to select, insert, update, and delete data based on the view, not the base tables. The view provides a filter that restricts the rows returned or modified.
For stored procedures that insert data, capture the user name using the same function specified in the WHERE clause of the view and insert that value into the UserName column.
Deny all permissions on the tables and views to the public role. Users will not be able to inherit permissions from other database roles, because the WHERE clause is based on user or login names, not on roles.
Grant EXECUTE on the stored procedures to database roles. Users can only access data through the stored procedures provided.
I'm no application designer but on the surface, your solution sounds unnecessarily complicated to me.
That said, you can issue the following query to get the Windows AD Login name of the user currently executing the stored procedure. You can use this information to cross reference with your mapping table to determine if the AD account has the required privileges to perform the operation.
SELECT SYSTEM_USER
Do keep in mind that this returns the name of the currently executing context, so keep in mind that this can be explicitly changed using the "Execute As" statement.
EDIT:
I wonder if perhaps a view could be used to limit the data visible to a given AD account. The Stored Procedure logic could then focus on the data modification aspect, rather than security implementation. Controlling your data access using views would also ensure that a consistent security access method is used across multiple stored procedures if required, as opposed to having to implement security checking within each.
Since writing this, the link provided by Martin Smith, details how this solution can be implemented:
Granting Row-Level Permissions in SQL Server
In conclusion, a combination of both is how Microsoft suggest you implement the solution to your problem.