Consider an Azure B2C - Business API integration, where a custom policy triggers an HTTP request (req A.) to business apis (REST API on AWS) for provisioning access to external systems.
Req A response time is currently limited by AWS/API Gateway to 30s but this is changing with requirements and might increase.
Considering Req A is so expensive, what options do we have in the custom policy for handling this type of scenario?
There is nothing in B2C Custom Policies specifically to handle this case. So your options are probably limited to whatever else you'd usually do for any API.
A few examples:
Cacheing: Instead of calling AWS API Gateway for the inquiry, you'd call another service which caches these results (like Azure API Management). This may or may not be a good idea depending on what type of claim you're grabbing.
Delayed Retrieval: Instead of populating the claim in the user token via B2C custom policy, have your application grab that value independently of Azure AD B2C.
Related
My organization has implemented authorization using Oauth on our APIs utilizing Azure AD B2C. We have different applications registered and have given them app roles that we ensure are on the JWT for authorization, as well as other claims we use for validation.
My question is it best practice to then use our own graph API credentials to handle changes on the backend of our API, or should we be using theirs?
For example, an application wants to edit a user in B2C. They call us with their JWT scoped to our backend API. We validate it and update the user. Should the update be performed using our own graph API credentials, or should we be performing some form of token exchange to obtain a graph token tied to their credentials somehow?
Azure AD B2C doesn't support on-the-behalf-of flow yet for API's. This being said, there is value of this design with complex resource API delegation models. This requirement generally is something that evolves from mature services due to acquisitions or just increasing data points from multiple sources but requires scale architecture.
For simple services that don't have 100's/1,000's of resource API's, then a simpler design (not requiring token exchange) makes sense.
Using something like Azure API Manager is ideally to put in front of your application. This gives you the typical control that an APIM provides. Other things it provides are:
DNS control for API endpoints that are not service dependent
Ability to do fallback logic by controlling endpoints and automation
A/B testing and release controlled by DNS
Requires no application dev change to update endpoints
Depending on industry, you may require/need OBO - for having the authorization Web API (API-1) not obtain user data in the original token - and data is in the 2nd token (API-2)i.e. resource API. Mostly it's a design requirement on how the API resources requires. I'd recommend looking at the OAuth token exchange protocol to see what makes sense for you. It's important to understand OBO does not align with the token exchange protocol.
I have created an HTTP Triggered Azure Function and exposed some endpoints. I am calling those endpoints from Salesforce Community.
https://<testing...>.azurewebsites.net/getData
https://<testing...>.azurewebsites.net/postData
https://<testing...>.azurewebsites.net/updateData
https://<testing...>.azurewebsites.net/deleteData
The Azure Functions Authorization Level is anonymous. I can access the responses from HTTP endpoints to the salesforce community site.
How can I set the authorization level so that, the endpoints can only be accessible from the Salesforce Community and the salesforce Users?
Thanks
There are quite a few options available like App Service Authentication or using API management for authorizing requests.
Have a look at Securing Azure Functions - Authentication/authorization.
While function keys can provide some mitigation for unwanted access, the only way to truly secure your function endpoints is by implementing positive authentication of clients accessing your functions. You can then make authorization decisions based on identity.
I got a HTTP triggered azure function, which is using by one of my web applications. The user of this site would be anybody who signed up to the site. Now I want to implement authentication to the azure function in such a way that only signed up user would able access the azure function through my web site. I could see many built-in authentications like azure functions, OAuth using Azure AD and other identity providers etc. I am looking for to way to authenticate users signed-up through my website, not with identity providers.
One solution I can think of is while signing up a register that user to Azure AD. Then while calling the API pass user credentials to the API and validate against AD. Can somebody please advice this is a good solution? If not please advise the best solution for my use case.
I don't want to use any external auth provider
Just referring to the documentation:
Azure functions HTTP Trigger - Authorization keys
While keys may help obfuscate your HTTP endpoints during development, they are not intended as a way to secure an HTTP trigger in production. To learn more, see Secure an HTTP endpoint in production.
The second link Secure an HTTP endpoint in production gives more insights on how to secure HTTP triggered functions:
To fully secure your function endpoints in production, you should consider implementing one of the following function app-level security options:
Turn on App Service Authentication / Authorization for your function app. The App Service platform lets use Azure Active Directory (AAD) and several third-party identity providers to authenticate clients. You can use this to implement custom authorization rules for your functions, and you can work with user information from your function code. To learn more, see Authentication and authorization in Azure App Service and Working with client identities.
Use Azure API Management (APIM) to authenticate requests. APIM provides a variety of API security options for incoming requests. To learn more, see API Management authentication policies. With APIM in place, you can configure your function app to accept requests only from the IP address of your APIM instance. To learn more, see IP address restrictions.
Deploy your function app to an Azure App Service Environment (ASE). ASE provides a dedicated hosting environment in which to run your functions. ASE lets you configure a single front-end gateway that you can use to authenticate all incoming requests. For more information, see Configuring a Web Application Firewall (WAF) for App Service Environment.
In my opinion you can do this in following ways.
Using function level Authorization key (Not preferred but easy)
If your web app is the only one that will access the function app you may enable authorization directly on the function. Any one who wants to access the function has to pass the key else you get 401 . Since you want your function to be accessed directly by users then you have to create additonal end point in your web site that will call function app on users' behalf and pass the key. You can find more about here
Authorization Key
Using Azure B2C or AD
You are thinking on the right lines. If your website is external consumer accessed then you may consider Azure B2C. You get many out of box functionalities including sign up using social logins and you may not need to save the users separately. The flow remains the same , users get authenticated by Azure AD (or B2C) and token is issued. The token is then passed when calling azure functions.
I was wondering if it's possible to add more then one authentication provider to protect an API endpoint via Azure API gateway.
From the portal, it doesn't seem like it is possible since it only allows you to select one? Wonder if there is a workaround?
For example, I want a user to be able to sign in to google and as well as facebook via openIDConnect. Based on successful validate-jwt in the policy of the API be able to hit the actual endpoints.
Only one provider can be associated with an API at the moment. But this association does not affect runtime request processing in any way, it's purely for documentation and test console purposed. So if those are not important to you it should not be a big deal.
I have an API hosted in Azure (Web App). This API can't be accessed directory by every client (IP Restriction), and I am willing to use APIM to protect it.
Users will call the APIM-Gateway and the gateway should responds appropriately.
One big problem is authentication: I am protecting this API (The Backend API and not the APIM-Gateway endpoint) with AAD.
So users should authenticate themselves against AAD and access the resources with no direct access to the backend.
Is it possible to implement such a scenario?
If you're fine with users authenticating against AAD then it's perfectly supported. With that model APIM may be used to just pass-through user requests to backend or you could use validate-jwt policy somewhere in request processing pipeline to validate users' tokens and authorize invoked actions.
APIM's authorization servers feature may be used to document that your APIs require AAD token from certain server. If this is done test console on developer portal will show controls to simplify getting token to make test calls to your APIs.
Normally APIM requires clients to pass subscription keys to authenticate and authorize calls. But if you're relying on AAD that may be not something you want - then you can use Open product to make your calls anonymous to APIM. validate-jwt policy can still be used to require certain token to be present with request.
There are various ways you can ensure that your backend is reachable only via APIM:
Shared secret - set a special header in APIM policy and check it's value on backend.
Client certificate authentication - APIM may be set up to attach client certificate to each request to backend that you will check at backend side to make sure that this is APIM making a call.
VNET - APIM can join your VNET, while backend may be setup to accept calls only within VNET making it possible to be called only through APIM.
I have used below approach in my recent project and used jwt validation to validate oauth2 token in policy
Follow Microsoft document link https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad.
Here is a quick overview of the steps:
Register an application (backend-app) in Azure AD to represent the API.
Register another application (client-app) in Azure AD to represent a client application that needs to call the API.
In Azure AD, grant permissions to allow the client-app to call the backend-app.
Configure the Developer Console to call the API using OAuth 2.0 user authorization. (optional)
Add the validate-jwt policy to validate the OAuth token for every incoming request.