I am fairly new to Power BI. I have two questions/clarifications:
Question 1:
I was wondering What type authentication is supported by Power BI datasets. I will explain with an example below:
Consider I have a Power BI dataset and some charts (a dashboard) in Power BI. The datasource is Rest WCF service on my premises. The users are my organizational users. The OData service is an HTTPS endpoint. I was wondering if authentication would work in that case? Would I be able to authenticate the user in this case. As my knowledge goes if the call to my rest service has a token in header, I would be able to call my STS and validate the user.
My question is when the dataset is refreshed, the call to my service (which is made from Power BI) does it also include a Token in the call header. I am assuming it would be because the user is already logged on to power BI using his/her organizational credentials. Can someone please confirm.
Question 2:
This question is again about user access/authentication. Consider that my organization has many users which have different level of access to data (some users would see more data/ some less based on user id). I develop some power BI datasets (models) and some dashboards. I as developer have access to all data, so essentially see all data. I then share them to end users.
The question is when any user uses the shared dashboards and refreshes the dataset, will his access (authentication) work and he sees only those data that he should ?
I am confused as to how this would work. Is it that when an user adds a shared dashboard into his profile, would he/she have his own copy of the dashboard/dataset or will it be an shared one. If it is a shared one then I guess the access thing would not work.
Please advise/suggest.
Girija
First question: if your data sources uses basic authentication it should work. You would build your Excel file or Power BI Desktop file to point to your data source, ensure it refreshes and then publish to the Power BI service. If you're looking for OAuth, then that is not something you can do on your side yet.
Second question: depends on how you implement your solution. If you're using the a REST API, the data is retrieved as the user who entered their credentials. So if you share your report built on your data source, then the people you share with see your data. However, if you use something like Analysis Service tabular as the data source, you can implement row level security in Analysis Service tabular, your users would instead login as themselves and see just the data they have permission to.
Related
I am learning SSO, so familiar with basic concepts.
I have a web application(Ruby on rails), where users are saved in Postgre DB (in AWS).
The users want to log in to another service(Rollbar) using the same user credential that they use in our application. In other words, I want to move the application's user information to an identity provider, so that the users can log in with the same credentials to the application and Rollbar using SSO.
One option I thought of is to move the users to Google workspace or Azure AD, but that is too much as I am not looking for any additional features
I did see services like Auth0 and Okta - just wondering whether I am going in the right direction
Any service name or links to documentation is appreciated
We already have DB with users.
We have to migrate all records to Keycloak DB or we can just implement Storage SPI ?
We don't want to migrate records, because we should also support old DB, it brings problems because we will need synchronize 2 DB.
Can you please write what could be the problems in this approach and write your advices for resolve theirs ?
USER DATA SOURCES
Moving to a system such as Keycloak will require an architectural design on how to manage user fields. Some user fields will need migrating to an identity database managed by Keycloak. Applications can then receive updates to these fields within tokens.
KEYCLOAK DATA
Keycloak will expect to have its own user account storage, and this is where each user's subject claim will originate from. If a new user signs up, the user will be created here before being created in your business data.
Keycloak user data will include fields such as name and email if they are sent in forgot password workflows. You can keep most other user fields in your business data if you prefer.
So to summarize, a migration will be needed, but you don't have to migrate all user fields.
BUSINESS DATA
This may include other user fields that you want to keep where they are, but also include in access tokens and use for authorization in APIs. Examples are values like roles, permissions, tenant ID, partner ID, supscription level.
DESIGN STEPS
My recent blog post walks through some examples and suggests a way to think through your end-to-end flows. There are a couple of different user data scenarios mentioned there.
It is worth doing a day or two of sketching out how you want your system to work. In particular how your APIs will authorize requests, and how you will manage both existing and new users. This avoids the potential for finding expensive problems later.
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I'm developing a system which, when submitting a form through Google Forms, a script will take the data from the sheet which the data is submitted to and then set up a project in a project management software (Zoho projects), and also create Google folder structures based on the information provided.
In other words, a google form is the one location from which all project infrastructure will be created in their corresponding locations and software.
In order for this system to work properly, I need every user who has access to the form to be able to perform the same actions on every software which the script is tied to, regardless of their permissions level for each.
This necessitates the script using only one set of credentials for the 3rd party API which is authorized at a high level, and having all users of the form access only those credentials in order to get the consistent results that are needed.
The problem with this is that I cannot (or at least I don't think I can,) use the OAuth2.0 library for GAS, as user authentication would be to access only the data which the user operating the software has; this would produce many errors in the code because utilizing credentials of different authority levels while attempting to perform the same tasks which require high levels of authority would yield many errors, and lead to inconsistent functionality with the script. On top of this, because I'm referencing a 3rd party API, there's no "Service Account" that I can use to act on behalf of highly authorized users.
To resolve this issue, I've built my own wrapper library for this API in Google Apps Script and built my own authentication system in which user credentials are automatically renewed and managed using the PropertiesService capabilities. I have established access to a highly-authorized user's data through this system. I access this data in my script instead of authenticating with the OAuth2 library for Google Apps Script in order to allow consistent results from the software.
I've found my own method that works for this scenario, but after all the work I've went through, am wondering if I have reinvented the wheel. Is there any other more established way to have multiple users interface with one set of credentials of a 3rd party API through Google Apps Script? Or is this a unique situation that required the solution that I came up with?
Thanks in advance!
You could instead use GAS to create webapp that runs as you every time, and then passes ownership of the related zoho and google drive files to the user after the script runs.
We're starting to migrate our Website to a REST Service based system and are in the process of developing the core right now.
In our current setup a user has one or more "accounts" assigned which define what data he can see on the website. Only one account can be active for a given user at any time. Right now we store the selected account in the database and use it to filter all queries.
Now I'm not sure how to handle this properly in a REST environment. Possible solutions I found are:
Sending the requested account with every request
Storing the current account in the auth token. (We're using JWT for that)
Having the current account stored on the server and calling a specific resource to change it
Each of these has its pros and cons for our setup. Currently we're using the 3rd approach in our Website. But what would be the correct way to handle such a thing in a REST environment?
Yea the design you are dealing with is fairly bad, and what you really want to do is remove the state completely out of this system.
For that reason the first option is by far superior:
Sending the requested account with every request
If this is simply an id, there's a very simple way to do this, just prefix all your (relevant) routes / uris with this account id. For example:
http://api.example.org/accounts/{id}/...
This way the 'state' is maintained by virtue of which url you are accessing, and the server can be unaware of the state.