I'm building a custom Power BI DataConnector which uses OAuth. I'm following the github example. But this stores client credentials (required for the 'code flow' in OAuth) as plain text files. Is there a secure alternative to this ?
Unfortunately due to the current "state of the art" there is no way to securely protect these credentials according to Microsoft staffer Curt Hagenlocher:
There is no way to protect a secret on someone's desktop. That's why some OAuth providers (like AAD) support a "native app" mode where there's a client id but no secret. The most recent development in this space is PKCE, and we're aiming to have sample code for that later this year.
In principle, a secret could be supplied separately for service use -- and I'd like to see us do that some day -- but there's a lot of infrastructure which would need to be created to support that.
I suggested encryption of the module itself and Curt's response was that this too would be ineffective:
All someone needs to do is have Fiddler running and they can see
exactly what secret is being sent to the token endpoint.
Full conversation:
https://github.com/microsoft/DataConnectors/issues/298
Related
We have a requirement to fetch data from a rest api into powerbi and schedule a refresh every night. The rest api support jwt authentication so it needs header with xapikey and access token.
I have managed to write a function in power query to get access token from our auth endpoint and able to inject access token for the rest api call and it works fine with powerbi-desktop. I have published the report to powerbi cloud.
The auth endpoint require username and password, we would not like to store this details in .pbix file and publish to cloud but instead use azure key vault and powerbi to fetch details at runtime.
Please advise ?
Power Automate has a great Azure Vault connector.
You could make a simple 3-action flow:
A post to that URL will json back the secret/credentials.
Now, here is the goofy part - hide that URL in a permissioned location (Onedrive, Sharepoint, etc). Have your pbi pickup from that location, using privileged credentials. Now the URL and the credentials get picked up at runtime, and neither is persisted in PBIX.
I am assuming that there is an available premium PAutomate env in which to spin up that flow, of course. But, given that you already have an azure vault, that seems like a standard PBI+ toolkit to have at that point.
We're in the process of configuring our suite of WSO2 products in a development environment and we're having a hard time wrapping our heads around IS Key Manager.
What we're going for is an Identity Server (already configured) with an OAuth Service Provider that an external web page can log into. This is already complete, we can get our token through IS just fine.
We now want to take the same token, and pass it to API Manager, and have API Manager understand the token, and the roles within, and approve or deny the API request.
Further in, we want to pass the token to Enterprise Integrator (which API Manager calls) and get info from the token (user info, claims) within a sequence.
IS is configured and working in it's isolated way (tokens generated from it aren't being accepted by APIM). APIM is configured in that it is pointing to an EI API.
EI is only configured in that it has an API with sequences that do stuff.
I've read through these:
https://docs.wso2.com/display/AM260/Key+Concepts#KeyConcepts-KeyManager
https://docs.wso2.com/display/AM210/Configuring+WSO2+Identity+Server+as+a+Key+Manager
They suggest a separate Key Manager that all can speak to. Makes sense. But the Key Manager when downloaded is an APIM instance? And looking deeper into the documentation it seems like this Key Manager is meant to REPLACE the traditional Identity Server, which doesn't support our use case (we need a separate Identity Server that can federate freely with others).
I assume I'm not understanding something about the Key Manager configuration properly.
In short:
IS needs to have an OAuth service provider to login to. Once the token is generated there, it will be sent to an APIM endpoint. APIM should understand the roles, and authorize it through. EI should then receive the token from APIM and then also understand the roles and authorize it through.
How can I accomplish this?
I would assume you got to the page where "API Manager" download page. Then you got the download pack named "wso2am-2.6.0.zip"?
There is a link on the same download page under "Other Resources" -> "Identity Server as a Key Manager Pack". You can get the "wso2is-km-5.7.0.zip".
This is almost same as "wso2is-5.7.0.zip", except very few config modification. You could use almost all the IS features in the same way.
I am trying to use Microsoft Outlook mail API in our web application.
Followed this tutorial https://learn.microsoft.com/en-us/outlook/rest/javascript-tutorial first, but some important thing is skipped in it.
[Skipped part]
https://learn.microsoft.com/en-us/outlook/rest/javascript-tutorial#using-the-id-token
This sample won't do all of the required validations listed in the
OpenID spec. Most notably, it won't validate the signature on the
token. Currently requesting the signing keys from Azure would require
a server-side component, so we'll skip that step for the sake of
simplicity. However, production apps should not skip this important
step!
In the example code:
// Per Azure docs (and OpenID spec), we MUST validate
// the ID token before using it. However, full validation
// of the signature currently requires a server-side component
// to fetch the public signing keys from Azure. This sample will
// skip that part (technically violating the OpenID spec) and do
// minimal validation
I have a server-side component created with Django, but I'm not sure how to fetch the public signing keys from Azure.
The actual feature I am implementing is sending email via HTML form. I chose to implement this feature on client-side due to several reasons. It's working and I'd like to make authentication secure before deployment.
Just clarify, I followed the tutorial above and use code from this repo to access Outlook API instead of Microsoft graph. The repo is introduced in the beginning of this tutorial.
Thank you in advance.
You have to find the jwks or cert endpoint in Azure by checking the well-known configuration for Azure (something like this). You'll be able to find all the active and enabled keys in the jwks endpoint in JSON format. You can parse those values inside your application and select the required key.
Does the Google Apps Email Migration API v2 support 2 legged oAuth1?
I've looked at this answer, but I believe it refers to the older version of the Email Migration API: Does Google Apps Email Migration API support 2 legged oAuth?
I have been able to authenticate an Email Migration API request using OAuth1 w/ tokens, but all of my 2 legged OAuth 1 attempts have failed. I have tried including xoauth_requestor_id and it has not had an effect.
There is some hinting in the docs that OAuth1 w/ tokens may be required, but I was hoping to confirm that that is the case.
For example the docs say: "If your application has certain unusual authorization requirements, such as logging in at the same time as requesting data access (hybrid) or domain-wide delegation of authority (2LO), then you cannot currently use OAuth 2.0 tokens. In such cases, you must instead use OAuth 1.0 tokens and an API key."
It seems clear there that "tokens" are referenced, however the word "token" is also used to describe the Authorization request header, so it is less clear that this means OAuth1 request tokens.
Any help is greatly appreciated. Thanks!
The section you are referring to doesn't seem up to date. You can have domain-wide delegation of authority using OAuth 2.0. It's called Service Account. Once authenticated, you do exactly the same that you used to do with 2-legged OAuth 1.0.
Here are the steps you need to get started:
Go to Google Developer Console
Create a project if you don't already have one
Go to APIs & auth --> APIs and activate the Admin SDK
Go to APIs & auth --> Credentials and click CREATE NEW CLIENT ID
Select Service Account and click Create Client ID
Download the p12 private key file (and keep it safe !)
Go to your Google Apps Admin Panel
Go to Security --> Advanced Settings --> Manage OAuth Client Access (Direct URL: https://admin.google.com/AdminHome?#OGX:ManageOauthClients)
Enter the Client Id you just created along with the scopes you'll need, separated with commas (In your case, https://www.googleapis.com/auth/email.migration)
Go to your favorite language client library documentation and find how to authenticate using the private key file you downloaded earlier and also impersonate your domain users.
Hope that helps.
We've Installed Pre-Packaged Identity Server 5.1.0 with API Manager 1.10.0 and use sqlserver as a data store.
We use OAUTH2 to authorize our API's and we want to map our local claims to a service provider (an application?). Behind the API we have a .Net Wcf Service with some logging where we read the header with WebOperationContext.Current.IncomingRequest.Headers["assertion"] and print the claims which are present.
The Claims which are returned are:
{"iss":"wso2.org/products/am"
"exp":1462357259751
"wso2url/claims/subscriber":"Sjaak"
"wso2url/claims/applicationid":"1003"
"wso2url/claims/applicationname":"DefaultApplication"
"wso2url/claims/applicationtier":"Medium"
"wso2url/claims/apicontext":"/Test/v1.0"
"wso2url/claims/version":"v1.0"
"wso2url/claims/tier":"Silver"
"wso2url/claims/keytype":"PRODUCTION"
"wso2url/claims/usertype":"APPLICATION"
"wso2url/claims/enduser":"Sjaak#carbon.super"
"wso2url/claims/enduserTenantId":"-1234"
"wso2url/claims/emailaddress":"sjakie#chocola.nl"
"wso2url/claims/givenname":"Sjakie"
"wso2url/claims/lastname":"van de Chocoladefabriek"
"wso2url/claims/role":"Internal/subscriber
Internal/everyone
Application/Sjaak_DefaultApplication_PRODUCTION"}
Where wso2url is http://wso2.org, but we cannot post this, because I don't have 10 reputation points...:(
The information in these claims is good, but only we want to use our own uri, so not wso2.org, but myorg.com. And we want to add other claims, with for example our own userId and some other stuff.
Among other things we have followed the guide for configuring claims for a service provider but had no success with this. We have made the assumption that an application is a service provider for which we can use the claims.
Has anyone got an idea what we are doing wrong? What do we need to do to add custom claims?
Thanks in advance!
[Added on 9th may]
Maybe this can point us in the right direction?
When we add a subscription to an application and we generate a new key than there is no new Service provider in the list:
The list of service provider without a new one for user Sjaak, so there is missing: Sjaak_CalculatorApp_PRODUCTION
But even when we do this for user admin the claims are not coming through. We have the following claim configuration and in my logging still the same claims as described above are there, no new ones, so no claim named accountnaam and no voogd.com uri:
Service Provider(SP) - It provides services to some end users and relies on a trusted Identity provider(IDP) to handle authentication and authorization for them. SP may use multiple protocols(Oauth2, SAML2, etc.) to communicate with IDP.
Claims are defined for SP, since same claims can be send over different protocols. In the default case, Identity server uses wso2 claim dialect(start with wos2.com) for claims. If you want a different claim dialect than this, use "Define Custom Claim Dialect" option in the service provider configuration. In there you can map wso2 claims(Local Claim) to your own claims(Service Provider Claim).