CloudEvents has a webhooks specification for event delivery: HTTP 1.1 Web Hooks for Event Delivery - Version 1.0. Among other things, the CloudEvents Webhooks spec details requirements for webhook validation and authorization. As described in the spec, CloudEvents webhooks authorization methods "lean on the OAuth 2.0 Bearer Token RFC6750 model".
Azure Event Grid supports CloudEvents: Use CloudEvents v1.0 schema with Event Grid
Event Grid's support for webhook authorization is limited to "adding query parameters to the webhook URL when creating an Event Subscription" as described here: Authenticating access to Azure Event Grid resources.
Given that an OAuth bearer token can have a limited lifetime, I therefore need a way to refresh the token. However, as far as I can tell Event Grid provides no mechanism other than hard-coding the token in the query parameter at the time the webhook subscription is defined.
Is my understanding correct? Any recommendations?
EDIT: In this scenario the webhook endpoint is an external endpoint not hosted on Azure. It is a 3rd party endpoint that simply supports the CloudEvents webhooks specification.
The documenent mentioned in your question such as Authenticate event delivery to webhook endpoints using Azure AD is not clear enough. It looks like there are described (mixed) two ways how to secure an event delivery to the webhook.
1.
I do recommend to use a way described in the first section of this document such as using the AAD to authenticate and authorize Azure Event Grid to deliver events to your webhook endpoint handler.
In this case, the subscription required to populate the following properties:
azureActiveDirectoryTenantId
azureActiveDirectoryApplicationIdOrUr
Note, that the validation process is not depended from the above properties, in other words, your subscription can be created successfully, but the event will be not delivered to the webhook endpoint for AAD authorization error.
In the case when the AEG based on subscription TenantId and ApplicationId values will get the access token (Bearer) from the AAD, the event is delivered to the webhook endpoint handler with the access token in the Authorization header.
Now, your subscriber handler has fresh (valid) access token for its usage.
2.
The second way, such as using a query parameter in the webhook url address is working like you mentioned. This secret value is hardcoded during the process of the creating subscription and it is not managed (refreshed/updated/etc.) by AEG.
Related
There is an API that I need to iteratively return data from in an Azure Logic App. To do this I need two HTTP steps, 1 to receive an access token and the other to use the token to be returned the data. Unfortunately, I can only receive the token through Oauth 2.0 Authorization and Azure Logic App does NOT have that authorization feature built into the connector (But I see Active Directory OAuth which seems different). Is there any way around this?
Trying to achieve the below. But the only concern I have is with Step 2: Logic doesn't have Oauth 2.0 Authorization
The available OAuth Authentication option is OAuth Active Directory which is specific to Azure and my requirement is for an external URL which only has client Id & client secret information
Tried below. Getting error
Logic app DOES have the Authorization feature built into the http connector. Click on the Add new parameter dropdown.
But this is for specific cases. In your case the credentials are in the body so you can use the native connector without any Authorization. Just add the headers and body that you need as below.
The body I used is like below (to match your body requirements):
{"client_id":"#{triggerBody()?['client_id']}","client_secret":"#{triggerBody()?['client_secret']}","grant_type":"client_credentials"}
If successful, You will need to parse the response so you can use the token from the response in the next actual call to the API.
I'm trying to use Azure AD to lock down access to authenticated users. I'm hoping someone could direct me to a setup that might fit the need here (and I feel like I must be overlooking the solution...).
We have an application that will expose various endpoints to be called by other teams in the organization. Nearly all of the consumers will be other user-less applications. (also none of these are Azure hosted/deployed services)
For auditing purposes, one of the requirements is the need to know what user (service) is calling any given endpoint.
Essentially, in the following:
We would need to be able to have Consumer 1 call My API, Consumer 2 call My API , and be able to determine inside of My API who the current consumer is.
I know with the client credentials flow, we could create multiple secrets and provide one to each consumer. However from the generated token, it appears that these are essentially both tokens on behalf of the Service Principal (so no way to know who the call is coming from).
I'd also looked into the ROPC flow, but I think am running into issue since we are using ADFS with our on prem AD servers.
Any easy button I'm overlooking? (fingerscrossed)
Please allow me to share my humble opinions here.
Firstly, access token is used for calling api which contains the information that if the token has correct scoped for the target api. And Id token contains the user informaion.
So if the Consumer1 and Consumer2 are on behalf of application itself, then it can't add user information within the access token and there's no id token for it. In this scenario, I think what you can do is adding an identifier into the request along with the access token, then your api application can both check if the token is illegal and which Consumer sends this request. This scenario used client credential flow to generate access token.
If the Consumer1 and Consumer2 are on behalf of users, or they are application but the request calling your api application can get the current user information, then you may send id token along with access token, or just send the user id as an identifier. This scenario may need users to sign in, so maybe auth code flow is better then credential flow.
The following page shows how can I purge Application Insights data -
https://learn.microsoft.com/en-us/rest/api/application-insights/components/purge
I tried following it but it doesn't mention how to use authentication and I am getting the following error in response -
{
"error": {
"code": "AuthenticationFailed",
"message": "Authentication failed. The 'Authorization' header is missing."
}
Can someone please guide me how do use the authentication header?
As per joy said in comment, just go to the website, and click "try it" -> log use your credential, then you can see the token:
On the page you linked to, scroll all the way up in the menu and find 'Getting started with REST'. When you click that and scroll the page, you find Register your client application with Azure AD.
Most Azure services (such as Azure Resource Manager providers and the classic deployment model) require your client code to authenticate with valid credentials before you can call the service's API. Authentication is coordinated between the various actors by Azure AD, and provides your client with an access token as proof of the authentication. The token is then sent to the Azure service in the HTTP Authorization header of subsequent REST API requests. The token's claims also provide information to the service, allowing it to validate the client and perform any required authorization.
Long story short:
Register your client application with Azure AD
Create the request
Acquire an access token
Assemble the request message
Send the request
Process the response message
You need authorization header to be added in your request to purge the azure application insights data. Refer for more details and step by step guide - https://sanganakauthority.blogspot.com/2019/06/how-to-delete-or-purge-azure.html
I'm using <log-to-event-hub> policy to log all the request and responses to event-hubs.This policy requires a logger-id which refers to the event hub where our logs will be streamed.To create this logger I referred https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-log-event-hubs . Where we send a PUT request to https://{your service}.management.azure-api.net/loggers/{new logger name}?api-version=2017-03-01 with the SharedAccessSignature token generated in the Management API section API Management Service.Now this token is valid only for 30days.That means the<log-to-event-hub> policy can log to this event-hub only for 30 days.
Today the SharedAccessSignature got expired.So all of my API's started throwing a 500 internal server error.How to renew this SharedAccessSignature automatically so that when its about to expire it automatically gets renewed with the new SharedAccessSignature.
I did not find any solution so I deleted the event-hub and created a new one with the new shared key.I will be storing all my logs in this event-hub so it should be running up everytime.Can anyone help me with this.
You're mixing up tokens here. The token you generate in "Management API" section is used to authenticate your call to create logger. This token is only needed if you choose to make that call via our direct api (xxx.management.azure-api.net) and not via ARM. This PUT call needs to be done only once to create a logger. The credentials that are used to talk to eventhub are passed inside payload of that call, see "credentials" here: https://learn.microsoft.com/en-us/rest/api/apimanagement/2019-01-01/logger/createorupdate#request-body. And it's those credentials you may need to rotate. See eventhub docs on how to create those credentials.
I need some help with Azure API Management service.
At the moment we have a SinglePage App which is using two Backend Services (WebApi .Net Core) hosted on Azure. To Authenticate and Authrize user we are using IdentityServer (also hosted on Azure as a service) + SubscriptionService. Here IdSrv is authenticating the user and it also defines to which APIs the webapp has access. The SubscriptionService has information if the user has rights to given APIs. More or less like that.
So the flow is:
WebApp -> redirect to IdSrv endpoint -> login -> back to UI -> ask backend with user credentials (token)
Now, we want to add Azure API Management to the mix and I am struggling how to do that...
Initially we were thinking that we can hide everything including the IdentityServer behind API Management gateway, but looks like this doesn't make sense or is impossible. I found this as a helpfull reference: Generate Access Token and validate against IdentityServer4 through Azure API Management in which the second answer is quite important remark.
Based on that I think that I need to leave the Client to use IdentityServer to authenticate as this requires UI interaction but then somehow set a global policy in API Management to authorize the user using mentioned Send-Request policy. And then change backend to accept the JWT tokens from this policy? Is my thinking correct? How to implement that?
Or I should just pass the authorization-header from client request through API Management?
All those things are new for me so it could be that I missed something or messed up the terms...
The way you integrate APIM into picture may depend on goals you want to achieve with APIM. You could hide IdSrv behind APIM since there is Client credentials flow that would allow APIM to authenticate/authorize itself to an API, or you could have user authorize APIM once via Auth code grant and then store refresh tokens and use them to talk to an API. But I'm not sure that would be best since it quite a bit changes you system and forces you to solve other problems instead, like how to authenticate user to APIM. In some cases this may be a good approach, it's up to you to decide.
If you're fine with keeping IdSrv facing user, then we have APIM receiving a token with every request. You could then have a global/API policy in APIM that would send token received from user to SUbscriptionService to check user authorization to make a call) can do that with send-request policy), and either let the call pass or deny. This approach is most useful if you want to use different auth mechanism between APIM and backend, because if APIM is doing authorization work, your backend could avoid checking any user access, and instead just authorize APIM to do everything.
Check out this sample on how to authorize requests using external service: https://learn.microsoft.com/en-us/azure/api-management/policies/authorize-request-using-external-authorizer
it is quite late from asking this question but here I described how we have done that. We cover UI clients and Device clients with SSL Certification auth on APIM. In short words:
UI Client is being redirected to ID Server Loging page
APIM is doing Token validation with ID Server
APIM is doing SSL Certification verification in DB and returning back token like data for devices to pass some "device account" information.
More details can be found here: