I would like to deploy a Logic App from VS 2017 into another tenants subscription. I am the owner of the target resource group but I am still getting the LinkedAuthorizationFailed error when using the deploy functionally within VS2017.
10:40:41 - "error": {
10:40:41 - "code": "LinkedAuthorizationFailed",
10:40:41 - "message": "The client has permission to perform action 'Microsoft.Web/sites/functions/listSecrets/action' on scope '/subscriptions/XXXX/resourcegroups/XXXX/providers/Microsoft.Logic/workflows/LogicappName', however the current tenant 'XXXX' is not authorized to access linked subscription 'XXXX'."
10:40:41 - }
I can create and manage logic apps via the web portal. But it should also be somehow possible to deploy via VS or?
I was a co admin before and I thing it worked than, but I can't expect the client to make me a co admin just to deploy Logic Apps.
This error is not related to the permissions to deploy a Logic App , but to get the keys of an Azure Function that is being called within the Logic App. You need to check that you have the correct permissions not only to deploy onto the resource group you want to, but also to get the keys from the Azure Function you are calling from the Logic App.
HTH
In my case I had a wrong azure function linked within the logic app.
After fixing the wrong subscription i linked there the error went away.
Related
I am testing some workflow in azure on which I have some web apps api connecting to a SQL Database using a service principle. Everything works fine and the web app is able to connect to the database using Managed identity. To test this approach, I also disabled (in the server => Azure Active Directory) the access using username and password and setting the admin group to be able to connect to my server using MFA. All this works just fine.
Once implemented this, I realise that my postman is not able anymore to perform any action. And if I try to send a GET or POST request to the api, I get the error
{
"response": {
"code": "unauthorized",
"reason": "User is not authenticated."
},
"statusCode": "unauthorized"
}
Which is fully understandable as I removed the access using username and password and enable only Azure active directory.
Here is my question, and I hope you can help me with this.
How can I grant access to postman to query my service using a service principle and what is the best approach to achieve this?
Thank you very much for your help and please if you need more info just let me know
The familiar approach for this problem is performing "Get Azure AD tokens by using a service principal".
Performing provisioning a service principal in Azure Portal.
Get AD access tokens.
Use the service principal’s Azure AD access token to access the Databricks REST API
Check the below documentation for step by step procedure.
https://learn.microsoft.com/en-us/azure/databricks/dev-tools/api/latest/aad/service-prin-aad-token#main
I created my azure web-app and created app registration. and connected Azure AD to my web app. I used express security and I also used advance security with client ID and client secret. I know there is a similar question about this error. but it is not clear answer.
Most likely causes:
IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.
IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.
IIS was not able to process configuration for the Web site or application.
The authenticated user does not have permission to use this DLL.
The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.
Things you can try:
Ensure that the NTFS permissions for the web.config file are correct and allow access to the Web server's machine account.
Check the event logs to see if any additional information was logged.
Verify the permissions for the DLL.
Install the .NET Extensibility feature if the request is mapped to a managed handler.
Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click here.
From your description, I know that the problem is most likely due to the lack of web.config file.
Solution:
It is recommended to ensure that your project can run normally locally.
Continuous deployment is recommended
At present, the reason for your problem is the lack of web.config, which will be automatically created when using git deployment. As shown below.
For more details, you can check my answer in another post.
Azure Web App getting “You do not have permission to view this directory or page.” when launch app
I have asked a similar question in a previous post, but I think this deserves it's own post.
In WSO2 Identity Server, I understand that service providers can be configured (on first startup only) if they are placed in the folder /repository/conf/identity/service-providers. I also understand that they are not visible through the management console ui if they are configured on first startup.
How do you edit them though? Let's say I want to want to edit the claims of an existing service provider? Change the allowed OAuth grant types? Even delete the service provider?
If I can't see the service provider in the console, how can I edit or delete it?
A follow-up but related question: What's the reasoning behind the "one and done" service provider setup that WSO2 provides? I expect to be adding service providers through the lifetime of my WSO2 implementation and it would be much easier if I could just place a file in a folder (the repository/conf/identity/service-providers folder that only works on first startup) and restart my server instead of going into the UI and performing multiple clicks to configure the service provider manually or upload it manually via file.
EDIT: #sajith pointed out that you should be able to configure service providers even after the server has started up once based on information in this article: https://docs.wso2.com/display/IS570/Configuring+a+SP+and+IdP+Using+Configuration+Files. However, I have not seen it work successfully. I know that something is happening because if I try to upload a service provider through the console (with a file upload) I get an error:
Console output:
Caused by: org.wso2.carbon.identity.application.common.IdentityApplicationManagementException: Application with the same name loaded from the file system.
So it looks like the WSO2 server is recognizing and loading the new service providers (even after the first startup) but I can't authenticate against them. Example response when attempting to authenticate against a new service provider:
{
"error_description": "A valid OAuth client could not be found for client_id: test",
"error": "invalid_client"
}
If I can't see the service provider in the console, how can I edit or
delete it? What's the reasoning behind the "one and done" service provider setup that WSO2 provides?
This document says you can restart the WSO2 Identity Server to apply the file-based service-provider and identity-provider configurations (configs which are placed inside <IS_HOME>/repository/conf/identity/) to the system.
I assume you have mixed with the following note regarding claim configurations.
The claims configured in /repository/conf/claim-config.xml
file get applied only when you start the product for the first time,
or for any newly created tenants. With the first startup, claim
dialects and claims will be loaded from the file and persisted in the
database. Any consecutive updates to the file will not be picked up
and claim dialects and claims will be loaded from the database.
Edit:
{
"error_description": "A valid OAuth client could not be found for client_id: test",
"error": "invalid_client" }
This is already answered in your previous question. invalid_client comes because you are setting a client id in the sp config file, but the identity server does not support to configure InboundAuthenticationConfig through this file.
Currently, the
InboundAuthenticationConfig in the deployed file is not supported.
But, you can have the SAML configurations in the
WSO2_HOME/repository/conf/identity/sso-idp-config.xml file.
Therefore, you may use SOAP admin services for that purpose.
I'm doing PoC of some GSuite custom solution which needs to listen to changes on users resource. I've created a GSuite account, linked it (and verified) with mytestdomain.com. It's also verified in API console. Basically followed instructions from https://developers.google.com/admin-sdk/directory/v1/guides/push
and fulfilled all requirements from there.
Unfortunately when I try to register my web hook I'm getting following error:
Watch request denied by backend [403]
Errors [
Message[Watch request denied by backend] Location[ - ] Reason[watchDenied] Domain[push]
]
I stuck with it and don't know where too look for more details about that error.
I'm using a certificate generated by Let's encrypt, but tested it with https://www.ssllabs.com/ssltest/ and got rank A. How to check if Google API treats Let's Encrypt as trusted CA?
Problem wasn't anyhow related to Let's Encrypt certificates. They're working just fine with Google's push notifications. I've contacted with Google support and with their help I've established that sending a request with showDeleted parameter set to true was a root cause of above problem.
Support guy claimed that documentation was copied from list method and that parameter cannot be used with watch method and they're going to update docs of watch method in API reference. (However it's still there).
We have been using Amazon SNS to send Android push notifications since April this year.
Pushes have sent with no problem, however there has never been any record of calls to the Cloud Messaging API in the Cloud Console (seems odd?).
Today I created a new API key for the Static Map service (unrelated) and renamed our Cloud Messaging API key (only the name, the key is the same). From this point no pushes have been sent, and trying to create a new platform application (or update the existing one) in AWS results in:
Invalid parameter: Attributes Reason: Platform credentials are invalid (Service: AmazonSNS; Status Code: 400; Error Code: InvalidParameter; Request ID:)
I have also tried manually making calls to the https://gcm-http.googleapis.com/gcm/send endpoint using the key which results in Unauthorized (401).
Interestingly, I can make calls to the above endpoint using the key I created today, however they fail on MismatchSenderId.
I can't see a lot of the previous options that the Cloud Console had (server / browser keys, etc) within the API Manager?
For those who are facing this in 2017, here goes a tip:
1 - Go to your firebase console (https://console.firebase.google.com/) click on your project (which you want to use for push notifications)
2 - Click on the "three dots" on the right side of your project name and click on "Settings"
3 - Click on "CLOUD MESSAGING" on the header tabs
4 - Copy the "Server Key" (this one is bigger than your API key)
5 - Paste on the "API Key" input of the AWS Form for "Create platform application"
PS: Note that this is valid only for GCM Push Notifications.
API Key management for GCM has been moved to Firebase Console.
You can create a new Firebase Project (or import an existing cloud project) and you should obtain a new Server Key for Cloud Messaging.
see the updated documentation:
https://developers.google.com/cloud-messaging/android/client#create-an-api-project
and the stack overflow question: Where can I find the API KEY for Firebase Cloud Messaging?
if you still have problems please contact:
https://firebase.google.com/support/contact/troubleshooting
I have been getting the same error when creating Amazon SNS platform application:
Invalid parameter: Attributes Reason: Platform credentials are invalid (Service: AmazonSNS; Status Code: 400; Error Code: InvalidParameter; Request ID:)
After reaching out to the Firebase support as suggested by Diego, this is the response I got from Google:
Hope you're doing well and thanks for reaching out to us.
I'm not really familiar with Amazon SNS and looks like their integration is still with GCM, not FCM. If your app implementation is still GCM, then you need to migrate with FCM in order to use the server key in the console. See the instructions here.
Also, Firebase has upgraded the server keys to a new version. We'd recommend to use the server key instead of the legacy server key.
I hope this helps. Let me know if you have any other concerns. Thank you.
This indicates that we'll have to change our app code. We were able to make this work for another app in out organization by creating a new firebase project and using the Legacy server key with Amazon SNS.
At some point we'll definitely upgrade to using FCM but at the moment we have a tight deadline.
Update:
So finally what worked for us is using the 'Server Key' under Project Settings --> Cloud Messaging . The app still uses the GCM implementation. Amazon SNS is happy with this key and generated a GCM platform push application. The pushes work !
Still confused about why the 'Legacy Server Key' does not work for one app but is ok for the other. But I am not digging into it any further.
For those starting a new project and wondering why it is still invalid, make sure the application Key restriction is set to Android apps. In my case, it was at only set to None and when I switched to Android apps, it worked after 5 to 10min after updating it. You'll need to add your package name and SHA-1 certificate fingerprint.