i am currently trying to create some Dashboard Reports using Power View for all Employees.
But i can't allow for any Users being able to see the Data of the other.
Is Power View capable of Determining which user is logged on and give that to my Tabular Project, so it can filter the data through the Dynamic Security implemented in the Tabular Model?
If you are using tabular SSAS (not Power Pivot) and you have your security set appropriately (with roles and row filters), and you are connecting to a tabular SSAS model (through a SharePoint shared data connection or BISM connection) with windows authentication that uses the current user's credentials, you can take advantage of the security in your tabular model. Excel does have the capability to get the current user and pass that context back to the model to apply the appropriate security when returning results.
Related
Currently I have the following scenario. I have a report in Power BI which reads from a dataset which has data of all companies. In my ASP .NET MVC application the user will select the company for which to display the report and with Power BI Embedded the application filters the report by the ID of the company through the embed config defined in JS (filter parameters passed from server).
I am using app owns data approach where I have a master account and the embed token is generated for the master account.
The user accessing the report does not have access rights to all companies and this is being handled server-side. With this approach however, the user can easily alter the embed config in JS and display the report for a company which he is not authorized to access.
I looked into row-level security and I found the following approach https://community.powerbi.com/t5/Developer/PowerBi-Embedded-API-Works-with-RLS/td-p/231064 where there exists a role for every company and the embed token is generated for that particular company. This would be an ideal approach but in my scenario the companies are not pre-defined and can be created any time. Therefore, I would need to create a role per company. This however cannot be achieved programmatically as Power BI does not provide means to automate role creation.
The only approach I can think of is to clone a report for each new company and create a dataset specific to that report which will only have the data for that particular company. Then the generated embed token will only be valid for that particular report.
Has anyone also experienced this dilemma? Any suggestions what I should do in such scenario?
You still can use RLS, but without roles per company. Use USERPRINCIPALNAME() DAX function to find out which user is viewing the report. In the database make a table to specify which company can be seen by which user and add it to your model. Then use RLS to filter this table to only the row (or rows) where user is current one (here is where USERPRINCIPALNAME() comes into play), and let the relationship between this table and your data tables to filter out what should not be seen. This way there will be no JavaScript filters at all, so nothing can be changed by some malicious user.
See Using the username() or userprincipalname() DAX function.
I have a customer that owns a carpet cleaning business and we have all of his different franchisee's data in a multi-tenant database model and we would like to move this data into a data warehouse in snowflake. I don't want to have to build a separate database for each customer because then I have to keep each database up to date with the latest data model. I want to use 1 data model to rule them all. I have a tenant ID that I keep with each record to identify the franchisee's data. I want to give a set of credentials to each franchisee to where they can hook up their analytics tool of choice (tableau, power bi, etc.) and only get access to the rows that are applicable to them. Is there a way to secure the rows they see in each table based on their user. In other words some sort of row level access control similar to profiles in postgres. Are there any better methods for handling this type of scenario? Ultimately I want to maintain and manage the least number of elt jobs and data models.
This is the purpose of ether Secure Views, or Reader Accounts.
We are using both, and they have about the same technical hassle/setup costs. But we are using an internal tool to build/alter the schema's.
To expand on Simeon's answer:
You could have a single Snowflake account and create a Snowflake role & user for each franchisee. These roles would have access to a Secure View which uses the CURRENT_ROLE / CURRENT_USER context functions as in this example from the Snowflake documentation.
You'd have to have a role -> tennant ID "mapping table" which is used in the Secure View to limit the rows down to the correct franchisee.
I have created a PowerView using a BISM connection in Enterprise Portal of AX. That PowerView report will be used by 100+ users. I want every user to his/her data in the PowerView instead of viewing the complete data. One option is to create 100+ security roles in SSAS (multidimentional) which is not a viable option. Please guide me how can i achieve dynamic security in PowerView so that every user sees its own view. Thanks.
Power View doesn't not offer any kind of security. You will need to do this in SSAS, but you don't need 100+ security roles. You will want to look into dynamic security. To create dynamic security, you will need some way to relate a user to the information they should see. This usually means adding a field to an existing table or creating new tables.
If all users are secured by the same attributes, they can be contained in a single role. If some users are secured based on one attribute and others based upon another attribute, then you may need multiple roles.
Here's how this might work.
Create a table that contains all users that will need access to your cube.
Create a bridge table that ties the users to the attribute on which you are securing their access. For instance, maybe users can only see certain products so you have a table of User IDs and Product IDs.
Add these tables to your DSV.
Create a user dimension.
Create a measure group based upon your security bridge table
Create a role for this user type and add an MDX statement to the Allowed Member Set. Also, set the Enable visual totals checkbox.
Populate the members for the role, preferably through an AD group rather than individually if you have 100+ users.
Your allowed member set will look something like
Exists(
{[Product].[Product ID].members},
STRTOSET("[Users].[UserName].[UserName].&[" + Username() + "]"),
"Bridge User Product"
)
You can find a good blog post here and a good video about SSAS security here (dynamic security starts around the 35 minute mark).
We have an OLAP project which uses Sharepoint 2013 Excel Services to show excel files that contains external data from SQL Server Analysis Services (SSAS) cube.
Our Authentication method to login users is FBA (Forms Based Authentication)
Our Goal is to show only subset of data from SSAS cube for each user based on their role which has already been defined in SSAS side.
Because of using form based authentication, roles don’t apply on excel files from ssas, Any Idea?
We faced this problem and I recall we fixed using Kerberos delegation. We needed the actual user to be passed to SSAS in order to row filter that user. It wasn't simple though. Follow this: https://msdn.microsoft.com/en-us/us-en/library/dn194199(v=sql.120).aspx
Good luck.
Finally we use Customized windows authentication form to handle this topic
MS Query, when connecting to SQL Server through an ODBC Data Source, uses the system procedure "sp_tables" to retrieve a listing of tables in the database. The source for sp_tables can be viewed but not altered. The problem with this procedure is that it will not return a table name for which the connected user has permissions to access only certain columns. It only returns tables for which the connected user has full SELECT access.
We are using database roles with explicitly granted access to tables in our data warehouse. We have a model for building security down to the field level, but cannot enable it due to the problem above. Most users are accessing through MS Query and Excel, because everyone has MS Office and we have trained them in its use.
Since many reports have already been built around this product, migrating users to another product is not an option at this time.
One suggestion has been to create views with only the available columns and grant select on those views. This would work, but 1) would defeat the purpose of field-level access and isn't too far off of our current "work-around" and 2) would require retraining the users on using the new views instead of the tables they are used to.