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.
Related
From Azure Data Factory, I'm trying to connect to a REST service that requires an access token (OAuth2).
Tried in Postman with the client credentials flow (client_id/client_secret) and it works fine:
Calling the token endpoint to get an access_token
Use the token in a subsequent request to retrieve data.
I configured the linked service like that as It supposed to support the OAuth2 client credentials flow:
But when testing the connection, it fails with this message:
The request body must contain the following parameter: 'client_secret'.
I don't really understand why the client_secret is not added in the request body as it is a client credentials flow.
Not sure if I'm missing some configuration ?
For the moment, I'm using Web Activity as a workaround.
This error may occurred because Allow public client flows is disabled for the application registered in Azure AD.
Enabling it may fixed the issue.
Refer - https://learn.microsoft.com/en-us/azure/data-factory/parameterize-linked-services?tabs=data-factory
Refer - https://learn.microsoft.com/en-gb/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=python#username-and-password
I implemented Microsoft login by referring to this Documentation. I am able to successfully get the Access token and call the Microsoft Graph API.
But when I created the App registration in the Azure portal. I came across the "Certificates and Secrets" Tab.
So I created a sample secret for my demo application as mentioned in the below screenshot.
But I am not able to find the exact use Case of this Secret variable. Is it used to authorize our Backend Node-JS server (Apis) or anything like that?.
It will be very helpful if anyone provided a sample use case with an example or any documentation reference. As I am completely new to Azure AD.
Thanks in Advance
The client secret is the password of the service principal. Using a certificate would be an alternative way to authenticate the SP.
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal#authentication-two-options
As per MS Document,
The application needs a client secret to prove its identity when
requesting a token.
This will help the application to be more secure.
Please refer Auth Code flow as an example reference. Here in first we need to request for a code in a get request and after receiving the code from the identity server then we request for an access token in a post request by adding client secret and code in the request. This allows the third person to can't figure out what the secret and code is, hence he can't bypass the security.
Our scenario is that we have an API which is currently only secured by a subscription key in APIM.
We plan to change this to also secure it with OAuth 2 following this guidance from Microsoft, we will then use the JWT validation policies within APIM to ensure that the user requesting access is a member of the appropriate groups to access given endpoints etc.
However as part of our release process we need to run some automated tests which call the API and check that certain data is returned.
Because these tests are run as part of an automated release pipeline we are struggling to understand how OAuth will fit into this process - as a user is required to enter credentials for a token to be issued...
We originally thought that we could just request a token manually once and then hard code it into the tests, but as tokens are only valid for a short time this isn't a good solution.
Other things we are considering are :
Creating a "test user" in AD and storing their credentials in the test project and then when the tests run we can request a token using the "Password" grant type and passing the username and password" however this doesn't seem like the best from a security point of view, even though the user would only have access to a very limited subset of the APIs functionality it still doesn't seem like a good practice.
Requesting a token using the client secret, however the downside to that is this is that the JWT does not contain the groups claim so this token will not pass JWT Validation.
This must be something that others have encountered? What is best practice in this scenario?
As you can see in the article you reference, you will be using Azure API Management to be the entry point to access your API. So, using the API Management you will have subscriptions with keys for your API. You just need to create a subscription for your automated testing, and save the key in the Azure Key Vault. And then during the deployment, you pull your subscription key from your Key Vault, and use it to call the API Management Endpoint, that consequently will call your API.
The solution that we went with in the end was to create a new App Registration for the Test project, then in APIM we added a rule so that the JWT policy is not applied to connections from that app.
Might not be the best solution but it works.
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 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: