I'm trying to setup a very simple Azure deployment that consists of a few Web Apps and an API Management Gateway through which all traffic is directed. The problem I currently have is that I am unsure as to the best way of blocking traffic from going direct to the Web Apps and bypassing the gateway. Is there a 'best practice' mechanism for ensuring only traffic from the Gateway is allowed through?
I've seen suggestions for IP range blocking and 'secret key' implementations, however I wonder whether there is a better way?
Thanks
There are a few options:
1. IP whitelisting
2. Secret key
3. Basic auth
4. Mutual cert auth
IMO #4 is the best way. You can find out more information on how to enable the feature in API Management and Web Apps here:
https://azure.microsoft.com/en-us/blog/enabling-client-certificate-authentication-for-an-azure-web-app/
https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/
I should I would add my own answer as I found that the new portal now has an 'API App' which allows access to API though internal only, e.g. through the gateway.
This seems to meet what I was trying to do exactly!
https://azure.microsoft.com/en-gb/documentation/articles/app-service-api-apps-why-best-platform/
Related
We configured Azure web app infrastructure such way that consist
customer web portal and WebApp API site
Scenario: when a user accessing a customer web portal where all requests communicate from Web API like (GET, POST, DELETE, PUT).
Here actually the problem is Web API portal is publicly available for now (but I don't know about for what extent Web API visible to users publicly still requires or not?).
In our case Customer ----API call should be in internal communication only there no third-party vendors supply.
Is there any methods secure the cus--API.
We tried to secure cus---API azure network restrictions in Web API network settings but that not helps us (we got stuck the complete cus--API communication is blocked)
As I mentioned Web API hide from the internet then we applied Azure AD authentication for Web API.
In this case, we got results were negative
we have no prior knowledge from code level securing and communication token generation
Finally, we looking for suggestions, and suggest me what are security checks to WEB APP-API COMMUNICATING WITH CUSTOMER PORTAL. WHAT ARE SECURITY CHECKS THAT NEED FIGURE OUT?
Another big problem is really WEBAPP-API put publicly if yes then what are the ways to tighten security.
Please share ideas and suggestion it would be greatly helpful to us.
Thank you
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
I have implemented web push using Firebase using Service-workers (which works only for https website). I want to use web push notification for http website.
I have read that it is possible to implement the web push for http website using some tweaks like subscribing to any third party.
Two questions I want to ask:
a) Is it possible to achieve the same without using any third party library?
b) How can I achieve the same behaviour for my website?
Any help is appreciated.
a) Is it possible to achieve the same without using any third party library?
From the developer guide: No, During development you'll be able to use service worker through localhost. but to deploy it you need HTTPS, the site registering the service worker must on on HTTPS and the service worker, which has to be on the same origin, will be served over HTTPS as a result. For security reasons. Having modified network requests, wide open to man in the middle attacks would be really bad
b) if you need web push notifications and you don't have an SSL take a look at Pushpad Express https://pushpad.xyz/
I've got a small ASP.NET web site, that calls another company (somewhat) Restful web service. My site has no logging currently. Is there an online service that can proxy all calls from my site and provide error logging and possibly retry functionality?
Have you tried https://ngrok.com/ - For local development, it's probably exactly what you're looking for.
If you just want to inspect the traffic your system is sending out or receiving, http://www.telerik.com/fiddler is a good choice.
I have a web role project in ASP.NET made for Azure deployment and need to have authentication.
I have to choose between Office 365 and On-Premise Active Directory.
Looks like both needs to be integrated to Azure Active Directory using Access Control Service.
What are the pros and cons of both?
Also if there are any other possibilities.
As astaykov mentions in his comment on your question you are not restricted to involving Access Control Services in this scenario. Not sure why he didn't submit that comment as an answer.
If you truly must go against your Office 365 or On Premise AD then what you are really saying asking is what is the difference between the two. I'll list some thoughts, but first if you want to implement these then here are some links:
Offerings from MS on Identity: http://msdn.microsoft.com/en-us/security/aa570351.aspx
Using ADFS V2 in your Azure Deployment:
http://channel9.msdn.com/shows/Identity/WIF-Workshop-9-WIF-and-Windows-Azure/ This is a little older material and I couldn't find much on using WIF to connect directo ADFS V2 that was more current. You do NOT have to invovle ACS in this at all. Sadly, this was misunderstood a lot when ACS was released.
Using Office 365/Windows Azure AD: http://msdn.microsoft.com/library/windowsazure/dn151790.aspx
Note: I have connected Web sites running in Azure to ADFSV2 directly, but I've not had a chance to work with the WAAD/Office 365 stuff yet.
If you choose to go with exposing your AD on premise then you would likely do this by exposing it using ADFS V2. This is what opens up the endpoint for the code running WIndows Identify Foundation (WIF) objects to reach out and deal with authentication. The upshot of this is that you don't have to worry about Office 365 logins or a WAAD separately and might be an interesting choice if you don't have those services for ANY OTHER reason but this one scenario. The down side is that you are exposing a proxy to your AD on an endpoint at your own location. If you lose connectivity to the internet then no one attempting to use the apps in the cloud would be able to authenticate. This is also the option I might look at if the users of the app in the cloud will ONLY EVER access it while behind your firewall (such as being at an office or even over VPN). This is because you can set it up so that your app uses a ADFS endpoint that is NOT exposed to the internet, but if they are behind your firewall it would still work. This pretty much ensures that only people already behind your firewall can use your app.
If you choose to use Office 365/WAAD integration then the upside is that you can sync with your onpremise AD to give single sign on to resources on your network as well as to the apps in the cloud. You also make access to your cloud apps more resilient because they have no need to depend on your exposed ADFS V2 endpoint. If you use Office 365/WAAD for any other reason (such as your employess use Office 365 for email, collaboration, etc.) then this is the option I would look at first.
You should look at ACS if you want to integrate with other identify providers such as Google, Facebook or even other companies. Technically you wouldn't have to use ACS at that time either, but it will certainly save you a ton of work to use ACS and not write the integration code on your own for each provider.