My goal is to periodically push data to a Power BI dataset using their REST API without user intervention.
It seems like the only way that's currently possible is to configure user credentials into the application and authenticate that way. All examples of the 'App Owns Data' strategy require some sort of user/password credentials.
I wrote an Azure WebJob that uses the credentials of a service account we created to authenticate with Azure AD and it's successfully pushing data to Power BI, but I'd like to do avoid having a service account just for this as it has cost and security implications.
Is there a way to use the Power BI REST API without user intervention and without logging in using Azure AD credentials?
Related
Inside Azure, am doing all authentication to my Azure SQL database over Managed identity.
However, by authenticating PowerBI on Azure SQL database, there are only "Organization Account" and "Basic Authentication". How can i make the authentication from PowerBI on AzureSQL over Azure AD in order to be safe against theft (e.g. Managed Identity...)?
When using an Organization Account Power BI never sees your password. Power BI gets and stores an Access Token and a Refresh Token from AAD.
Furthermore, if you are using a Gateway any credentials are encrypted with the Gateway's public key, and can only be decrypted by the Gateway, which is a server you control.
In the future Power BI may add managed identity auth, but the current options are not insecure, just sometimes inconvenient.
Also you can run a script to update the Access Token for a data source using an access token generated for a Service Prinicpal or Managed Identity, but you have to run the script on a schedule so the Access Token doesn't expire, which I think is like 55min.
And for Azure SQL you can force SSO so the end user's identity is used to access the database, not the identity configured in the data source.
My scenario is there are various tables with Aws redshift database and I need to produce a report out of it based on a SharePoint item id and show it in either in SharePoint Online page or spfx
I am stuck and trying to find various ways to achieve the above, I am completely new to aws. I have tried creating sample aws redshift cluster ,database, tables, lambda function ,http api etc
I tried creating a .net core web api and used connectionstring to connect to aws redshift host but I am using username and password in the connection, I have read about iam role and and also secrets manager but confused as to which is the better way to embed user credentials in web api and if so how to do it..not able to find a article for the same.. ... even though if I create the .net core web api and if I try to create a http api and lambda integration how will the authentication work
since if I call the above private aws http api within spfx but SharePoint will pass Azure AD credentials, how will we authenticate a aws http api. Is there any better ways to call 3rd party aws apis within SharePoint online with authentication other than azure, how can it be achieved?
Or is it that there are some other ways to retrieve aws redshift database tables and show it within SharePoint page or SharePoint spfx...
I did check out the option for Power BI but not sure how helpful will that be if there is huge anount of data in redshift database
Any help is highly appreciated
Thanks
I'm trying to understand overall power bi gateway security. There is one thing that I completely can't find any documentation. As I understand gateway connects to the azure service bus to pull query tasks. How this connection between gateway and Power BI Service is secured? What credentials / secrets are used and where it's stored?
I'm a beginner when it comes to Google Cloud. I have only worked with AWS before, but for this purpose I want to give Google Cloud a try.
I want to create an application where I don't have human users, but instead there are multiple instances of the same client application trying to access the pub/sub service. I would like each one of these users to come to register with my cloud function, which in return will:
create a pub/sub topic that only this client can listen to
return an identifier/key/something that can be used to authenticate the client the next time
How should I handle the authentication in this case? Should I create service credentials for each one of the clients? Or is there a way to provide a custom Identity Provider?
The first question is answered in this answer.
For the second one, the best way is for the user to be identified with Google oauth (a.k.a. a Google account).
When you create the pub/sub topic for this user, you should have already identified them, so you can set the proper permissions on the thread. Then, the user can simply call the pub/sub endpoint identified.
GCF, GAE apps, apps running on GKE, ... all of those have service accounts associated with them, so there should not be a problem to properly identify each client app running there.
If those users don't have an account (e.g. the client app is running outside of GCP), you can ask your human users (the ones running the client apps) to either:
Authenticate with their user account on your client app
Create a service account in GCP and make the client app use it
If those are not options, you can create a service account for each of your users, and provide the proper service account key file to each client.
So since parse is shutting down we are moving our website / mobile app that we've been developing to AWS. We are primarily going to use the following services:
SNS, SES, Dynamo, S3, Lambda.
Now I am still a bit confused on:
what cognito is used for? Do we really need cognito to authenticate users and use DynamoDB, S3, SNS ? Or can we just use specific APIs for each of these services and connect directly (using Js SDK)?
If we do have to use cognito how do we save local data i.e logged in user/ identity? is that what cognito sync is for or do we have to use cookies ?
In summary why do I need cognito when I can directly connect to DynamoDB using the JavaScript SDK?!
Thank you in Advance.
Amazon Cognito can be decomposed in two sub-services: Amazon Cognito Identity and Amazon Cognito Sync.
Think of the former as an authentication service and a credentials provider. The latter is just a service to store user data and keep it synchronized between multiple devices.
What is the purpose of Amazon Cognito Identity?
Suppose that you have a table in DynamoDB. Let's say that you have a web application that will store an item on that table.
You can create an user in IAM, embed the credential information on the web application, and then put the item on the table using the AWS SDK.
There are three things going on here:
The credentials are embedded in the application
The credentials do not expire.
Every user in your application has the same access rights on your table
This may be fine for some applications, but Amazon Cognito Identity offers a solution to these common problems.
Let me explain Cognito Identity's workflow:
An user registers an account on your application, sending all the information (username, password, other data...) to your server.
The server stores the user in some back-end database (it could be a DynamoDB table) and creates a new identity on the Cognito service. This identity is then mapped to this user.
The user can now login into your application. The user logins and sends username and password to your server. (This process could be done automatically after account registration)
The server checks the username and password against your back-end database. If everything is right, then the server makes a request to Amazon Cognito for a temporary access token.
The web application receives the token and makes a request to Amazon Cognito (using that access token) to get the user credentials. These credentials are basically a temporary IAM user that was created specifically for this user. It will have an expiration (usually an hour).
The web application uses these credentials to make operations on AWS, such as putting an item on a DynamoDB table, or calling a Lambda.
When the credentials expire, the user must re-login into the application. This might be done automatically or not, depending on your application's requirements.
On the Amazon Cognito dashboard, you can configure roles and policies for your "identities" (an user in Cognito). This way you can specify which services it can access. It even allows you to create access roles for your users (Admin users may be able to access some services that normal users should not).
I should also note that Amazon Cognito can be easily adapted to support Facebook / Google+ / Amazon accounts, which will be mapped to the same identity, so the user can login via multiple sources.
What is the purpose of Amazon Cognito Sync?
Consider it like a DynamoDB table where you store information for a specific user. These information is shared between multiple devices and is always synchronized. This means that when a web application updates an user value, then the mobile application will automatically reflect this change.
There is a limit on how much user data you can store (I don't remember now), so it's not something you would use to persist information (such as an user password), but rather a mean to share information.