I am wondering if it is possible to do conditional cross-domain calls to the service only when a "vendor key" is given to an authorised 3rd party.
Remotely:
When the service is called by some authorised remote server, service enables CROS feature, but a "vendor key" is required as a parameter or cookies.
Locally:
When the service is called by its own web server, ajax calls are accepted as usual. The "vendor key" parameter is not required when local server hits a CROS service.
Could you please give me some direction on how to implement it?
Here's the implementation of the EnableCors Request Filter Attribute.
Just change the implementation to look at the incoming IHttpRequest and only print the headers when your conditions are met.
You can also do this with a global request filter or adhoc, manually - in your service implementation.
Related
So, I have an API in Azure-API-Management, which is attached to a function. I want to expose one the method in API as Web-hook for another application CRM. It will be an inbound web-hook.
Is it possible ?
A webhook endpoint is like any other HTTP endpoint that usually expects a POST request from an external system. So, yes.
Depending on the CRM Application, you could leverage APIMs built-in security features to authenticate the webhook call without having to validate credentials in your function as a bonus for using APIM.
I tried to implement custom Authentication via a authentication endpoint in an azure mobile app. I've created an Api Controller, that creates the Jwt using Azures AppServiceLoginHandler.CreateToken method. When I post to this controller with turned off Azure App Service Authentication, I get a token, but when I want to use it later, I always receive a "401 Unauthorized".
But when I turn the setting on in the Azure Portal, and send the very same request
I get:
The requested resource does not support http method 'GET'.
I'm not changing any code, and I'm certainly using a POST request - The exact same request, that works with turned off App Service Authentication.
My Code is essentially the same as here:
https://www.newventuresoftware.com/blog/custom-authentication-with-azure-mobile-apps
Could someone enlighten me here? Do I need additional configuration somewhere?
As adrian hall's book about Custom Authentication states as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
For custom authentication, you need to turn on the Authentication / Authorization in your app service for authenticating your token. Moreover, I would recommend you leverage fiddler to capture the network traces to narrow this issue. Additionally, you need to make sure that you send the custom login request with HTTPS. Details, you could follow this similar issue.
We have API exposed to our customers through API Management. The security is handled using subscription key which is expected in "Ocp-Apim-Subscription-Key" header.
One of our methods supports polling trigger specifications, with "Location" and "Retry-After" header in response. For one of our customers we want to create Logic Apps, that would fire some actions on this trigger.
We set up HTTP trigger where we provided "Ocp-Apim-Subscription-Key" header in inputs parameters.
Here is the problem. The header is added only to the first request. Subsequent requests using "Location" url don't have this "Ocp-Apim-Subscription-Key" header, so they are rejected by API Management proxy.
I verified that header is in fact missing with some mock API, so it's definitely on Logic Apps end.
Does anyone have any idea how to resolve it?
I'm new to Web API, HTTP and security in general, but I just want to know if this is possible: for a controller to relax security requirements when the HTTP request originated from within the local area network.
My particular application has very low security requirements for clients inside the firewall. For instance, I want internal client apps to be able to make requests of controller actions marked with [AllowAnonymous] so that they don't need to deal with OAuth, etc (which just seems like complete overkill for my internal use scenario).
However, if the same controller actions are available to the public Internet, of course strict security requirements should apply.
Can security be handled differently based on origin? Or is the standard practice to expose both a public-facing and an Internal API?
When you use the [AllowAnonymous] attribute on your controller or action, you tell ASP.NET that it should not check the user's identity at all. That is not what you want for users coming from the internet.
You could remove the [Authorize] attribute from your controller and manually check inside the action if the user is authenticated using:
if (User.Identity.IsAuthenticated || IsLocalUser())
{
// action implementation
}
You can implement this check in a custom authorization attribute.
This still leaves you with the task to determine whether the user is local or coming from the internet. You could check the client IP-address to determine this of course.
Another option would be to enable both Windows authentication and bearer scheme authentication if your local users are part of an Active Directory domain.
Users from your intranet could use Windows authentication to talk to the service, while internet users need to bring a JWT token. This would only work if the client application for users coming from the internet is different than for local users.
DISCLAIMER: I've never tried this last option.
Identifying a request as one from "inside the firewall" isn't always as simple as just investigating the IP address. Although, this may work for you now, it may make it difficult to move environments or modify the environment without affecting application logic.
I would recommend developing a simple middle layer application that simply has the job of calling your main application with enough authorization data to handle security in the same context as your regular app, but this middle layer would in itself not be authorized. You will then just have to make sure that this app is not accessible to users outside of the firewall.
I need to call a rest service using HTTPS as part of my SI flow. I may additionally have to send user name and password as headers to authorize my access. What are the tools available to configure this in spring integration?
Thank You
HTTPS should "just work".
You can set headers with a header enricher and set mapped-request-headers on the outbound gateway to ensure your headers are mapped.
For more sophistication, you can customize the RestTemplate and inject it into the outbound endpoint.
See here for an example of configuring the underlying request factory.