I try to get list filesystems and their properties in the Azure Storage account using request:
https://<account_name>.dfs.core.windows.net/?resource=account
with one header Bearer
and get response
"error": {
"code": "AuthorizationPermissionMismatch",
"message": "This request is not authorized to perform this operation using this ******"
}
But when I make request for list paths:
https://<account_name>.dfs.core.windows.net/<filesystem>?recursive=true&resource=filesystem
I get a response with correct data.
Can you give me some advice on what is wrong?
P.s. My auth params.
enter image description here
I tested the same request in my environment by getting the token using client ID and secret. I received the same error as you are getting :
As a Solution ,
I added Storage Account Contributor role to the Service Principal
which I am using to get the bearer token as below:
Then , I get the bearer token using below client_credentials method:
After the above, When I perform the same request again then it gets
successful:
Related
I have an API Gateway fronted by CloudFront. The API Gateway has a regional endpoint with api key disabled. An Authorization header must be sent to the regional endpoint or the endpoint returns "Missing Authentication Token" as expected.
Using the same request on the CloudFront endpoint returns the following 403 Forbidden error:
{
"message": "The request signature we calculated does not match the signature you
provided. Check your AWS Secret Access Key and signing method. Consult the service
documentation for details.\n\nThe Canonical String for this request should have been\n'POST
// sensitive data here...
}
The Auth token is created from an AWS signature. The signature originates from an IAM role that allows invocation on the endpoint: "Action": "execute-api:Invoke"
Any ideas on why CloudFront isn't able to use these credentials to hit the API Gateway endpoint?
In summary,
"Postman w/ Authorization header -> API Gateway endpoint" works.
"Postman w/ Authorization header -> CloudFront -> API Gateway endpoint" returns the above 403.
UPDATE: Adding information on how I obtain the signature.
IAM Role:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:us-west-2:{ACCOUNT}:{ENDPOINT}",
"Effect": "Allow"
}
]
}
AccessKey, SecretKey, Session Token are obtained in CloudShell:
$ aws sts assume-role --role-arn arn:aws:iam::{ACCOUNT}:{ROLE} --role-session-name {SESSION_NAME}
These 3 keys are then used in Postman's Authorization tab. I select "AWS Signature" type and provide the AccessKey, SecretKey, and SessionToken.
From here, I can hit the API Gateway endpoint and receive 200 response. With the same request and headers, hitting the CloudFront endpoint results in the 403.
UPDATE #2: Adding information on CloudFront configuration.
The distribution behavior for the API GW origin is using the CachingOptimized policy. Its also allowing all HTTP methods.
I have configured our Azure Data Factory with a REST Link Service. I have obtained a valid token from the end service.
The token successfully works when using the token with POSTMAN, but the token returns Error status code 401 Unauthorized with Azure Data Factory.
As you can see with POSTMAN when I send a GET request with the Token I get data back:
However, with Azure Data Factory I get the error:
{
"errorCode": "2200",
"message": "Failure happened on 'Source' side. ErrorCode=RestCallFailedWithClientError,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Rest call failed with client error, status code 401 Unauthorized, please check your activity settings.\nRequest URL: https://pm2.preqinsolutions.com/apiCore/api/countries.\nResponse: ,Source=Microsoft.DataTransfer.ClientLibrary,'",
"failureType": "UserError",
"target": "Copy data1",
"details": []
}
The ADF Link Service is a follows:
Can someone see something obvioius that would prevent access due 401 Unauthorized status with ADF?
I have also tried the following ADF configuration. However, I'm getting the same error:
Please try changing the authHeader name to Authorization and the value to Bearer <your API key>. I suspect from the screenshot of Postman that is what it’s doing. If that does not work then please provide a link to the documentation. This explains Bearer tokens.
You might also check the lifetime of your access token and make sure it doesn’t expire after an hour, for example.
I did a quick test against a REST API I know (Power BI REST API). The linked service looks like this and the value for the Authorization header was Bearer MY_ACCESS_TOKEN_HERE.
The dataset looks like:
The source of the Copy activity looks like:
This succeeded.
I would suggest you contact pm2.preqinsolutions.com support to see if they can provide more information on your access token / API key and have them confirm that the API isn't restricted to be accessed from only certain allowed API addresses. (ADF will not be accessing it from an on-premises IP address like your laptop.) You might also change the REST API linked service to use a self-hosted integration runtime instead of an Azure integration runtime to validate the IP address the API is called from isn't the issue.
I have an AWS architecture like this:
An API Gateway with many endpoints. One of them is "/graphql"
The "/graphql" API Gateway endpoint points to a "/graphql" AppSync endpoint
My API Gateway uses COGNITO_USER_POOL to authentificate users. When an user makes a request to "/graphql" endpoint of API Gateway, he must to add id_token to "Authorization" header on the request. It works well.
My integration method on API Gateway gets the "Authorization" header and puts it on AppSync request using this HTTP Headers mapping:
Authorization = method.request.header.Authorization
It seems to work correctly also. Nevermind, I got this AppSync error when requesting the API Gateway endpoint:
{
"errors": [
{
"errorType": "UnauthorizedException",
"message": "Valid authorization header not provided."
}
]
}
It doesn't seems to be a token problem, because it works correctly when I request the AppSync endpoint directly (with the same Authorization header).
I observed that API Gateway adds some headers on the AppSync request, to generate a Signature. So my question is: Is there any way to do a request on AppSync from API Gateway without pass the Signature, only the id_token that user got from Cognito User Pool? I'd like to ignore IAM and use only the token (as I do when the request is done directly on AppSync from Postman).
Many thanks!
I have been struggling with this particular issue in GCP. I am trying to generate service account keys using Rest API calls outside of GCP. Below is screenshot of the service account along with the roles.
The as far as i can tell the Service account "Service account admin key" is the parent to create, list, etc child permissions.
So when invoking the Rest API call to generate key using this documentation:2
I get the below error
{
"error": {
"code": 403,
"message": "Permission iam.serviceAccountKeys.create is required to perform this operation on service account projects/XXXYYYZZZZZZ/serviceAccounts/XXXYYYYZZZZZZ.iam.gserviceaccount.com.",
"status": "PERMISSION_DENIED"
}
}
What am I missing?!
Updated: Adding additional screenshots of how i setup authorization and testing of Rest API call.
Following your steps, I was able to replicate it without any errors. As an alternative you can generate an access token instead as authentication.
Add an Auth Header. Generate a Bearer Token by using the command below:
gcloud auth application-default print-access-token
Remove the API Key to your URL. This sample URL retrieves:
https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_NAME#PROJECT_ID.iam.gserviceaccount.com/keys
Add keyTypes
USER_MANAGED
Add access token from the gcloud results above.
See sample screenshots below:
You can also refer to this if you want to generate service account keys, just make sure you update your URL, add a JSON body with keyAlgorithm, and use POST instead of GET. For more info, follow this guide.
So my requirement is for the application running on Azure Machine to check if a particular Azure user logged in belongs to an assigned Azure group.
I have enabled Managed Service Identity for the said virtual machine.
MSI
I get the token for the VM by making a call to the metadata service running locally using the following command for the graph resource on the VM:
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fgraph.windows.net' -H Metadata:true
Once I get the token I make a POST request to the graph API of isMemberOf with that newly acquired token:
curl -i -H "Authorization: Bearer <token-value>" -H "Content-Type: application/json" --data '{"groupId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","memberId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}' https://graph.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/isMemberOf?api-version=1.6
I get the following response
{"odata.error":{"code":"Authorization_RequestDenied","message":{"lang":"en","value":"Insufficient privileges to complete the operation."}}}
I have assigned the resource group the VM belongs to with IAM as a owner to the resource
Am I missing something that I should have it configured or I am doing something wrong here?
So I dug around a little bit and found that Microsoft prefers us developers using Microsoft Graph rather than the Azure AD Graph
Microsoft Graph vs Azure AD Graph
I found a similar call in Microsoft Graph API to get member of information User list member of call
This call requires the following scope:
Directory.Read.All
Directory.ReadWrite.All
And these are the steps I followed:
Application would need to fetch the token for making the Microsoft graph API call.
POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
HEADER
Content-type: application/x-www-form-urlencoded
BODY:
client_id=&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=&grant_type=client_credentials
RESPONSE:
{
"token_type": "Bearer",
"expires_in": 3600,
"ext_expires_in": 0,
"access_token": "<token-value>"
}
Client secret is generated at app registration time.
Application would make the call to microsoft graph API to fetch
POST https://graph.microsoft.com/v1.0/users/{user-object-id}/checkMemberGroups
HEADERS: Authorization: Bearer {token-value}
Content-Type: application/json
BODY:
{
"groupIds":["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"]
}
RESPONSE:
200 OK - if user belongs to the group
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(Edm.String)",
"value": [
"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
]
}
404 Not found - if user does not exist
{
"error": {
"code": "Request_ResourceNotFound",
"message": "Resource 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does not exist or one of its queried reference-property objects are not present.",
"innerError": {
"request-id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"date": "2018-05-23T02:54:47"
}
}
}
This would help application identify if the Azure user belongs to the assigned group or not.
You are calling Azure AD Graph API, not ARM API.
The IAM blade only gives access rights for the ARM API.
You'll need to assign the necessary rights to the service principal kinda manually.
I actually wrote an article on this a while back: Calling your APIs with Azure AD Managed Service Identity using application permissions.
You will need:
Your MSI service principal object id (you can see how to find this in my article)
The target service principal object id (in this case Azure AD Graph API)
Id of the app permission you want to assign (you can use e.g. https://graphexplorer.azurewebsites.net to find these, they are under appRoles on the service principal)
Once you have these, then you can run this PowerShell cmdlet (using the AAD v2 cmdlets):
Connect-AzureAD
New-AzureADServiceAppRoleAssignment -ObjectId msi-sp-id -Id app-permission-id -PrincipalId msi-sp-id -ResourceId aad-graph-sp-id
Then everything should work.