Is there a method to secure a Manual Http Trigger in a logic App with Basic Authentication.
Is this achieved through APi Management.
The authentication mechanism used by Logic Apps is based on SAS keys that only a user with management access to the resource can list. In case any of the keys are exposed, you can use the /regenerateAccessKey operation on the logic app. See this article for details.
In addition there is a capability to restrict firing a logic app if not coming from a specific range of IP addresses. This is not yet surfaced in the azure portal (as of 2016-11-09), but could be done manually via PowerShell and/or the management APIs.
For any other authentication mechanisms you would indeed want to use API Management as a frontdoor to your logic apps.
Related
I am working on one API which will be exposed to a couple of external clients. And I would like to limit access to my API and let only trusted 3rd parties access my API. I have found that Azure API Management provides subscription keys, which can be used to protect API - https://learn.microsoft.com/en-us/azure/active-directory-b2c/secure-api-management?tabs=app-reg-ga
Moreover, I see that I can connect my API to Azure AD - https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad, which might be useful if I want to restrict access based on roles and types of external systems (for example some external systems will have one role that allows using some additional features)
Could you please help me to understand all other cases when I must use Azure AD instead of subscription keys? And can I use them together?
I also would like to understand which approach is the best for me if you want to give access to the client apps (browser, mobile apps and etc.). As I understand, Azure AD B2C can be the best option here
For your requirement, if APIM is not necessary (you do not need to configure the exposed url of your api by APIM), I suggest you to just use Azure AD to protect your api. You can refer to this document.
If APIM is necessary, and your requirements do not need to limit multiple permissions for different role to access the api (in other words, you just want client can/can't access the api). You can implement it just by subscription key as you mentioned in your question.
If APIM is necessary, and your requirements need to provide different permissions for different roles to access the api, you can do it as the second document link you provided. You can validate the roles or other claims of access token to provide different permissions to client.
We want to build a central authority to do authentication and authorization for our various applications (.net). We see IdentityServer4 is open source and free, while Auth0 cost money. Does anyone use both of these? Can anyone provide suggestion which one to choose and why?
IdentityServer is a library that implements various authentication (not authorization!) protocols and let's you consolidate access control into a single system. You can host it in a typical ASP.NET webapp, console app or anything else, as long as the HTTP endpoints are available. It also lets you store the user data anywhere you want, whether in-memory, databases, flat files, the asp.net core membership system, or anywhere else.
Auth0 is a company that provides a managed service that handles authentication for you. They run the infrastructure and provide access through their website and APIs. It's similar to having someone run IdentityServer4 for you and there are several competitors like Okta for Devs, AWS Cognito, Azure AD B2C, Google Cloud Identity/Firebase, and more.
Choose IdentityServer if:
You want free open-source software.
You have the time and effort to run it yourself.
You want to control the backing data store (SQL database, Redis, JSON file, etc).
You want to manage all the data yourself due to regulations, privacy, etc.
You need complete control and flexibility around what happens during authentication (for example, merging user accounts in your database when someone signs in). It's all just C# code so you can do whatever you want.
Choose Auth0 if:
You want to save time and effort on implementation and operation.
Price is not an issue (as it can get expensive for some features).
The limited customizations offered by Auth0 are enough for your app.
You want the other features they offer like password-breach monitoring.
You don't want to manage user data, or don't mind having it stored by them.
Update as of Oct 2020 - IdentityServer is now a product from Duende Software with a new commercial open-source license to sustain development. There are other alternatives like OpenIddict that are still free.
Identity Server means building a server application to handle authentication and authorization, which can replicate what Auth0 does for OpenIdConnect (OIDC) there will be a few things to implement even if you use IdentityServer4. You will need to build that first, then integrate your application.
Auth0 allows you to integrate immediately with OIDC with additional & enterprise features.
Both of them implement federated protocols i.e. WS-Fed, SAML and OpenID Connect.
In order to use them your apps. need the appropriate client-side stack.
If they don't have this, you can't use the products.
The only alternative is pass-through, i.e. Auth0.
Or look at ADFS which has pass-through via the ADFS WAP.
If you do have the stacks, both will do the job.
idsrv4 does not have a user management portal e.g. create user, add group to users OOTB.
Auth0 does.
idsrv4 essentially adds features by code. Auth0 has config. via wizard.
idsrv4 is open source so you can customise to your heart's content. I find it really useful to bridge systems.
Azure AD is another option.
(intro)
I am new to Google Cloud Endpoints and I have started to build some HTTP REST services.
The purpose of those services is to be consumed directly by the users of my application (Business to Consumer - not business to business).
(The question)
I need to secure my services in a way to have only registered users being able to retrieve sensible data (and after login). My main purpose is to have the list of registered users saved in my database on CloudSQL (Dont want to use FB of Google Accounts). I was not able to find particular information about this point in the official Google documentation regarding authentication.
Can anyone advise me of the way to proceed and suggest some tutorials?
Thank you in advance.
The Endpoints proxy can validate JWTs, and we provide a couple of alternatives for creating those. Both Auth0 and Firebase have good user management capabilities and client-side libraries for generating JWTs. Both allow you to choose an identity provider (like FB or Google) or simply use username/password.
Check out the documentation here.
If you don't want to use Auth0 or Firebase Authentication, you can sign JWTs yourself with a private key and just give the proxy the URL of the Public Key (see the "Custom" tab on that same documentation page).
As far as looking up individual users in the database, you would have to do that part on your own.
I am connecting to my Azure mobile services server through my javascript files. Meaning i create the client in the controllers page and sort/update/delete data there. Is this a safe way to access my database? Do I have to use another way?
You can control access to the table as a whole with the access
property:
authenticated means you must be logged in to access the endpoint. If you are not authenticated, a 401 Unauthorized response will be
returned.
anonymous means anyone can access the endpoint.
disabled means the table is invisible. The server will return a 405 Method Not Allowed response.
Normally, you would only use authenticated as an access value at the
table level. You can also set access at the operation level, and that is
why this option exists. Anonymous access is the default.
From https://shellmonger.com/2016/04/15/30-days-of-zumo-v2-azure-mobile-apps-day-8-table-controller-basics/
You can do this from Easy tables settings in the Azure portal.
Before you change the table permission to authenticated, you'll need to add authentication to your mobile app first. For more information, please refer to this tutorial.
Controlling access to your database via a REST API where you can do authentication and authorization checks plus data validation is absolutely the right way to go. Azure Mobile Apps is just one way to get there (in my, potentially biased, opinion, it's one of the better ways). However, it isn't the only way. You should certainly consider your requirements when making such a decision.
I have been trying to determine a good strategy for authentication between a single WPF application of which calls to Web API services.
The client WPF app should be the only application to ever call the Web API.
I think I do have some unique requirements I must abide by. For example, The boss does not want to use ssl in any way; he is paranoid of users may having to deal with certificates.
Like I said, the client application is the only client using the Web API. The API just calls a list of stored procedures on a separate server.
Currently, we have a user membership database that does not align with any membership db standard, but we currently have over 200,000 members. One of the stored procedures currently authenticates the user with the membership db. The client application requires valid users to sign in to the application at start-up, however, we are wanting to secure all of the Web API requests sent from client to prevent non-valid requests being made to the server and so to prevent.
We are concerned about using the individual accounts or local authentication to essentially authenticate every web API request because of the added cost.
I have been thinking that what we are really needed to do is pretty much authenticate that it is our software client(WPF application) making the request and this authentication could open up all the controllers and actions for requests made by the client rather than the user. The user and its authentication is somewhat separate and is in place to prevent unauthorized users on a particular machines install of the application.
So you must have a valid user account to use the application.
Any suggestion would be great. I am just asking to get pointed in the right direction. I am really new to security so all suggestion will be valuable to me.
Thanks.