Hide / remove columns from certain users in a SSAS tabular model - ssas

I've got a nice SSAS tabular model with users processing away. Certain users need access to certain information, such as confidential info (e.g., SS numbers), that should not be visible to everyone. How should I handle this?
This indicates that there is no way to use roles to remove columns, only rows. Is my only option to make a copy of the model and maintain both? This can't be such an edge case...
I guess I can jury-rig something with a scm fork and code-generation, but I'd rather not go down that road.
Alternatively, is there any way to hide the columns (per user/role), so that at least they don't show up in client tools?

One method that requires very little additional development is to use the method described in the following blog post. http://blog.westmonroepartners.com/a-workaround-for-column-security-in-the-sql-server-analysis-services-bism-tabular-model/
The blog contains a link to an SSIS package which will replicate an existing cube, with the exception of the sensitive data columns. The users who cannot view the sensitive data columns can be given access to the second cube that does not contain sensitive data columns.

One way to achieve this is to create Perspectives. You can create different perspectives for different group of users. And end users can connect to their specific model.

Related

How to see how many people are accessing a ssas cube?

I wanted to know how many people are accessing a particular ssas cube. Please let me know the process to find them.
I don't think there's a simple way to get connected users from a cube. You can use a couple of different tools to collect that information (along with lot's of other information as well).
To get a list for users currently connected to a SSAS instance, you might use SQL Server Profiler. Then you can filter one cube from the resulting data.
For tracking users extended period of time, you can use Extended events
Both of these tools create data for a lot of data and you'll need to parse distinct users from that is some way.
To see the current sessions:
SELECT * FROM $System.DISCOVER_SESSIONS

I'm a new CDS/Dataverse user and am wondering why there are so many columns in new tables?

I'm new to CDS/Dataverse, coming from the SQL Server world. I created a new Dataverse table and there are over a dozen columns in my "new" table (e.g. "status", "version number"). Apparently these are added automatically. Why is this?
Also, there doesn't seem to be a way to view a grid of data (like I can with SQL Server) for quick review/modification of the data. Is there a way to view data visually like this?
Any tips for a new user, coming from SQL Server, would be appreciated. Thanks.
Edit: clarified the main question with examples (column names). (thanks David)
I am also new to CDS/Dataverse, so the following is a limited understanding from what I have explored so far.
The idea behind Dataverse is that it gives you a pre-built schema that follows best-practice for you build off of, so that you spend less time worrying about building a comprehensive data schema, creating tables, and how to relate them all together, and more time building applications in Power Apps.
For example, amongst the several dozen tables it generates from the get-go is Account and Contact. The former is for organisational entities and the latter is for single-person entities. You can go straight into adding your user records in one of these tables and take advantage of bits of Power Apps functionality already hooked up to these tables. You do not have to spend time thinking up column names, creating the table, making sure it hooks up to all the other Dataverse tables, testing whether the Power Apps functionality works with it correctly etc.
It is much the same story with the automatically generated columns for new tables: they are all there to maintain a best-practice schema and functionality for Power Apps. For example, the extra columns give you good auditing with the data you add, including when a row was created, modified, who created the row etc. The important thing is to start from what you want to build, and not get too caught up in the extra tables/columns. After a bit of research, you'll probably find you can utilise some more tables/columns in your design.
Viewing and adding data is very tedious -- it seems to take 5 clicks and several seconds to load the bit of data you want, which is eons in comparison to doing it in SQL Server. I believe it is how it is due to Microsoft's attempt to make it "user friendly".
Anyhow, the standard way to view data, starting from the main Power Apps view is:
From the right-hand side pane, click Data
Click Tables
From the list of tables, click your table
Along the top row, click Data
There is an alternative method that allows you to view the Dataverse tables in SSMS – see link below:
https://www.strategy365.co.uk/using-sql-to-query-the-common-data-service/
To import data in bulk:
Click on Data from the top drop-down menu > Get data.
Importing data from Excel is free. To import from other sources, including SQL Server, I believe is a paid service (although I think you may be able to do this on the free Community Plan).

Best way to create a shared data source with Report Builder

I am using report builder 3.0 (very similar to SQL server reporting services) to create reports for users on an application using SQL server 2012 database.
To set the scene, we have a database with over 1200 tables. We actually only need about 100 of these for reporting purposes. But it is very common that we need to combine fields from multiple tables together to get a common resource of data that my colleagues and I need for our reports.
Eg if I want a view of a customer, I would want to bring in information about the customer from the customer_table, information about his phone details from the Phone table, information about his account(s) from the accounts table and so on. Then I might need another view of the accounts - account type, various balance amounts, opening date, status etc.
What I would love to do is create a "customer view" where we combine all these fields into a single combined virtual table. Then we have an "Accounts view". It would be easier to use, easier to manage etc. Then we use this for all our reports going forwards. And when we need to, we can combine the customer and accounts view to use on a report plus actual tables into one combo-dataset to use on a report.
I am unsure about the right way to do this.
I see I can create a data source. This doesn't seem right as this appears to be what one might do if working off 2 or more databases. We are using just 1 database.
Then there are report models. It seems these are being deprecated and phased out so this doesn't seem a good option.
Finally I see we can create shared datasets. However, this option (as far as I can tell) won't allow me to combine this with another dataset. So using the example above, I won't be able to combine the customer view and the account view with this approach to use for a report to display details about the customer and his/her accounts.
Would appreciate guidance on the best way to achieve what I am trying to do...
Thanks
I can only speak from personal experience, but using the the data source approach has been good for our purposes. We have a single database with 50+ tables in it. This is linked to as a shared data source in the project so is available to all 50+ reports.
We then use Stored Procedures to make the information in the databases available to the reports, each report has it's own Stored Procedure that joins as many tables as required to provide the data for the report. The advantage of using Stored Procedures also allows you to only return rows you are interested in, rather than entire tables.
I'm not certain if this is the kind of answer that you were after, but describes how we solve a similar (smaller) issue.

Completely hide table on SSAS Tabular

I have a requirement that I'm not sure If I should use perspective or roles or a combination of both.
Basically there is a table on my tabular cube that certain users cannot see so I created two perspectives, one with that table and one that hides the table. That is great but nothing stops users from selecting the perspective that has access to the table I want to hide.
So I created a role and on the "dax filter", I added "=FALSE()" (according to this post https://msdn.microsoft.com/en-us/library/hh213165.aspx?f=255&MSPPError=-2147217396), which prevents values from being displayed but the problem is that the table is available to be selected.
What's the best way to solve this requirement?
Thanks
Unfortunately, there is no way to hide table name for a specific user in SSAS Tabular.
As you know perspective is not a security solution and The best way is prevent displaying value by creating Roles as u did.
Regards,
Arman

How to phrase an answer, data is separated at the logic / programmatic / application layer?

How do I describe the partition of client data when all data is stored in one place and separated via programming?
If a collection of data from various clients is stored in a variety of SQL tables and is separated via the code (E.g. members from different orgs defined by organisation table) at which layer is the data separation defined?
Sorry if this question is a bit poorly worded.
In terms of how to explain it, I'd need more information on how you're actually separating the data for consumption by different members, but we've done a similar thing using SQL views. In our case, it's pretty easy to explain because each role (i.e., a set of user permissions determined by their need-to-know) has a set of SQL views they have permissions to view and query but not modify. Then users can query the views as needed to make their own reports and datasets.
If you're looking for more technical jargon, this was one of the documents we came across when setting up our security.
It might be easiest to explain that each data element has a set of roles that have access to that data element. Your role within the multitude of client organizations determines which data elements you can work with in your reports. Then you would just want to use very strong language indicating how you have implemented safeguards ensuring that users cannot, in any way, access data that is not relevant to their need-to-know.