I would like to integrate Foundry with the central API gateway of our organisation.
Access of the gateway should be granted via OAuth2 via the "Third Party Applications" functionality of Foundry.
Now I am facing the problem, that our API Gateway only supports the Client Credential Flow in which no Authorization Token is used but only the Access Token. Is there a possibility to make Foundry follow the simplified flow w/o Auth token?
Foundry supports the OAuth2 Authorization Code grant which provides delegated access to Foundry resources and services.
Support for the OAuth2 Client Credentials grant, which allows service user access, is under limited release with a few customers. If it’s not available for you please reach out through your internal support channels. A general release is expected early this spring, I'll try and update here if that timeframe slips.
Related
We want to make our APIs available to external systems.
Our APIs are protected by "Access tokens" using OAUTH2 and Azure AD B2C as an Identity Provider.
Unfortunately, B2C does not support the "Client Credential Flow", so external systems cannot get tokens from B2C by passing their client id and their secret.
We are thinking of fronting the APIs with Azure API Management, and providing the external systems with Subscription Keys. Then once we verify the subscription key in API Management, we want to acquire an Access Token to call our back-end.
Is this possible? It seems like not because of the Client Credentials flow missing. However, I've seen videos from APIM experts claiming that it is possible. I'm I missing something? Does APIM have special treatment?
I'm doing some tests with Azure APIM and have already published an API on the developer portal. I have the docs, have it secured using OAuth2 with Azure AD with client_credentials flow. I can invoke this API from Postman and from the developer portal.
Unfortunatelly, the client_id and secret are set on the configuration and the developer cannot self service them. Is there a way to do so instead of having to add it manually to each developer?
I was looking for something like this: https://tyk.io/docs/tyk-stack/tyk-developer-portal/portal-oauth-clients/
Azure APIM itself doesn't act as an identity provider like tyk but instead uses Azure AD (or rather any OAuth 2.0 provider).
The configuration in the docs is primarily to get the Developer Portal Console (the one used to test APIs) to work. For the actual API calls, there is no configuration required.
The validate-jwt policy is what takes care of preauthorization of requests.
Since you are looking for the client credentials flow alone, you could simply expose a portal that can create the required app registrations on your Azure AD using the Microsoft Graph API and expose the client id/secret to your users.
The current developer portal doesn't support this as of today but is something you could contribute to if you wish.
We are using PubSub for queuing utilizing a push subscription pointing at an http-triggered cloud function. According to this documentation Cloud Run and App Engine will both authenticate requests from PubSub, cloud functions isn't listed. We have used other google services, like scheduler to invoke functions which require authentication, but have not had luck doing so with PubSub.
My question is, does cloud functions support authentication from PubSub through a subscription aim account set, or is it required that the function read and deal with the JWT itself for authentication?
You need different things:
A service account with the role/cloudfunctions.invoker
tick the Enable authentication
Select your service account
Add the Cloud Function URL (as provided in the Cloud Function) in the audience field. It's the missing part in the Ricco answer
EDIT 1
PubSub needs to have the authorization to generate a token on a service account. Check the first step on this. There, it shows how to grant the pubsub service agent service account as token creator.
Pub/Sub subscription supports the use of service account authentication for subscriptions using "Push".
To use service accounts just specify the endpoint of the cloud function, enable authentication and add a service account to be used to send requests to the cloud function. Make sure that the service account has the appropriate permissions to access both PubSub and cloud functions.
I have an ASP.NET Core REST API Service hosted on an Azure Web App. I own its source code and I can change it if required.
I am planning to publish REST API Service with Azure API Management.
I am adding Azure AD authentication to the Azure API Management front. So, the API management front is secured. All the steps are is described here.
All good so far. Here is the question (or challange?) :
Considering that my backend REST API Service is hosted on Azure and publicly accessible, how do I protect it against the request calls other than the API Management Calls?
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
A link to a code sample or online documentation would be a great help.
Update
While there are some overlaps with the follwoing question:
How to prevent direct access to API hosted in Azure app service
... part of this question is still outstanding:
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
You can enable static IP restriction on your WebApp to only allow incoming traffic from the VIP of your APIM Service facing ( keep in mind in some specific scenarios , the VIP may change and will be required to update the whitelist again).
Clients ==> AAD==> VIP APIM Service <==> (VIP APIM allowed) Web App
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions
Our EWS managed API application is currently using basic authentication with service account.
We are planning to change it to use OAuth authentication due to basic authentication won't work in 2020.
Will OAuth works with windows service in which there will be no user interaction? can we use OAuth Token from Azure AD when making EWS requests to read, update and delete user's calendar for on-prem exchange server and exchange online?
OAuth will work with a Windows service, using client credentials flow, AKA two-legged OAuth. Until Exchange 2019 appears, you can only do this with Exchange Online and Azure AD tokens.
One other thing: not only won't Basic Auth work in 2020, but I believe all of EWS will be deprecated in lieu of the Graph API by 2020.