I have two web apps in azure one angular 6 the other one is .net core web api. Angular app consumes the apis to get data. Some of these apis are public apis. It means authentication is not needed for them to be called.
My questions is, what the best approaches are to protect these public apis? By protecting, I mean not letting anonymous users to call these apis and abuse data.
In my mind these are what I can do:
CORS, but the problem is postman and other rest tool still can call my apis
Using azure api management? By rate limiting? Is there a better way?
Use some sort of api key but the angular app will expose them anyway.
In my c# app I get user agent, host, Origin of the call and restrict based on those?
Basically I want to restrict anonymous user from manipulating and calling my post apis and push not relevant or duplicate data to my back-end without using any sort of AD as my apis are going to be public. I want only a few authorized app can call my apis.
Please tell me which one of the above are the right one and please recommend a better approach.
P.S: my backend is .net core 2.2,
Thanks
I can recommend below solution,
Host your APIs on Azure API app and import it to APIM. Then Configure IP restriction on API APP using the IPs of APIM. That mean, only APIM can access your API host. or you can implement client certification authentication between APIM and API host.
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates
02.Next enable subscription key/API key on APIM and keep these key on Azure key vault. So you don't need to hard code these keys on frontend. I hope you host this Angular app on Azure. (I am not Angular expert...just check online for docs)
https://learn.microsoft.com/en-us/azure/key-vault/quick-create-node
03.Later based on your scenario, If need you can apply Rate policies.
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/api-management/api-management-sample-flexible-throttling.md
Related
I am using the Docusign Authorization Code example (https://github.com/docusign/code-examples-csharp) to create a C# application connected to Docusign (which is already configured with our Single Sign On).
I also have another Azure App Registration to invoke my Custom API from Azure and I need to successfully get a token to invoke it.
I have successfully used MSAL javascript to invoke the custom API.
However, I am not sure if this is the safest or should i go with MSAL.NET (to do everything server side).
Anyone got ideas how to incorporate this additional MSAL.Net auth to my existing Docusign based C# code.
Thanks in advance !
I think both MSAL js, and MASL.NET are secure, but there are some limitations to what you can do with the former. If all you need is a token to invoke an API - you should be good, but Microsoft support more things that you may need the server side code for.
This article has a table that tells you all the different authentication flows Microsoft supports, and the different features each of them supports.
I have a c#-based program that can send messages and files to our SlackWorkspace via my SlackApp (I'm using HttpClient to communicate with Slack).
Now, to distribute this program in my workspace and to make it so that every user will have his own identity, it says that I have to use OAuth and create verification-tokens, specific for each user.
It says in the Slack-documentation I have to use a redirect-URL (as per docs) to my own server.
We have a server that I potentially could use for this. But I have never done anything like this before and I am unclear on what "answer" I have to provide from our server. I thought the verification-process would be handled by Slack.
Anyone has an idea on how to approach this?
And before anyone asks - yes we need to install it for everyone and make them identifiable as themselves. We can't use the "SlackApp" as user. :)
I would be very grateful for code examples(in c#) and explanations on how this whole redirect-thing is working.
Slack uses the standard Oauth 2.0 protocol to authenticate apps, similar to Google and Facebook.
So the "verification-process" is indeed mostly handled by Slack (as outlined here), but your Slack app needs to initiate it and handle the responses properly. Also its a multi-step process and includes the user having to login into Slack with their credentials. This why you need a web app to handle the whole process.
To enable a Slack app to generate tokens via Oauth a web app is needed:
can be reached from the Internet
able to handle HTTP requests like a web server
has persistent storage for the newly generated tokens
This is probably easier to implement with ASP.NET Web Pages, which can utilize many functions from an existing web server.
But for this answer, lets look on an implementation in .NET Core. For that we need to create our own web server and some rudimentary session handling. Main concepts include:
HttpListener class for providing fundamental ability to listen and respond to HTTP requests
Handle multiple requests in parallel
Cookies / Session handling
MD5 hashes
The details go a bit beyond the scope of one answer. But I am happy to share a working example implementation on this GitHubGist.
Btw: For the local development of such a web app its recommend to use a VPN tunnel like ngrok, that allows one to expose a local machine securely to the Internet and Slack.
We have a whole bunch of clients that want us to start using their ADFS to allow their users into our web app using Single-Sign-On.
After reading up on WIF (which seemed to be the solution at first but is deprecated in VS 2013...), OWIN, oAuth, OpenID Connect, I'm completely confused as to the simplest way to implement SSO.
What is the best and simplest technology to use to implement SSO on an existing VS 2013 json restful service written in C#?
Ideally the technology would already be part of .NET.
Are there any code samples or tutorials out there for this scenario?
assuming that you want to consume your service from native clients, I would recommend that you protect your service using Web API middleware (which was already supported via OWIN middleware in VS2013) and implement your clients using the ADAL library. For a post specifically on ADAL and ADFS, see this. For more details on the Web API side of the solution, see this. If you want to target a variety of client platforms, you can find a complete collection of samples (for Azure AD, but easy to modify for ADFS) here.
This can be implemented through WSO2 IS as Relying Party in ADFS. When we will implement this setup the outcome/Income claims will be main source for User Profile load to WSO2IS for authentication and pass the SAML Response to SP(End URL of your application).
Refer the below links to configure WSO2 IS as relying party for ADFS and WSO2 IS configuration too.
https://omindu.wordpress.com/2015/06/19/setting-ad-fs-3-0-as-federated-authenticator-in-wso2-identity-server/
SSO would mean its Active Directory driven, or direct to IIS machine.config authentication instead of a web.config, but also considering the "simplest technology" you've mentioned, then this must be a call for something simple yet you can transform into what you really desire.
With this, we can refer to token-based web services authentication.
Here's a sample project from which I started and able to transform into something else. From here I think you can then change all authentications into AD or DB connect, or even both across your web services.
http://www.codeproject.com/Articles/9348/Web-Service-Authentication?fid=145460&df=90&mpp=25&prof=False&sort=Position&view=Normal&spc=Relaxed&fr=26#xx0xx
hopefully this would help.
I have a WinRT app that is going to interact with a WebAPI service on my server backed by an Entity Framework managed SQL database (MVC - ASP.NET). For security, I'm only allowing users authenticated on the WinRT side with the Microsoft Live Connect SDK to interact with the WebAPI service. I already have the login code for authenticating with the Live Connect SDK on the WinRT app side working. The WebAPI service is running in the context of an MVC Web Role running on my Azure hosted server.
I've done a lot of reading on StackOverflow and there's a wide range of documents on the topics of authentication, OData, OAuth, Azure Mobile Services, WebAPI and how to combine them:
Live Connect Authentication Token for use on Azure Mobile Services (REST)
How to use a MVC WebAPI OData endpoint securely?
Disable Windows Authentication for WebAPI
I am very concerned that I choose the tools/path that implements only what I need to implement the above scenario and in a secure manner. My main attack concern is un-authenticated users trying to access the ApiController and performing harmful Puts or Deletes. Some questions:
Do I need Azure Mobile Services at all?
What tool(s) do I use or configuration changes do I need to make to manage/pass the Live Connect token between the WinRT app and the service?
Is there a template or NuGet package that I should use that automates much of this?
Is there a document that addresses my scenario or one close to it?
Is there anything built-in to Entity Framework that can help, or conversely has a vulnerability I need to address? If so, what?
What changes do I need to make to the server configuration (web.config)?
here's my setup:
I have an MVC3 site hosted with a www subdomain (e.g., www.example.com). My site is secured via SSL and forms authentication, backed by ASP.NET membership/role providers. I have HTTP handlers providing service capabilities under /services (e.g., www.example.com/services). These are secured through Basic authentication over SSL. I have mobile devices successfully accessing/consuming these services. I have also created a new site with an api subdomain (e.g., api.example.com) that will be my public-facing API. These services are exposed currently via WCF Web API preview 6 (eventually to be migrated to ASP.NET Web API). These services are also secured via Basic authentication over SSL. My ASP.NET membership implementation stores hashed passwords (i.e., they are not encrypted). All services serve JSON responses. All of this stuff works great.
Here's my dilemma:
I started to write a new view on the MVC site and realized it would be great to use Ajax. My specific case is to implement cascading drop-down lists. I wanted to implement this using jQuery and a new service under the api subdomain. At first I thought this would be a simple exercise and then I realized, I have no effective way to call into my own API. My clients (mobile devices) all store their username/passwords locally so this is easy. However, if the same user is logged into my site, I have their username but not their password so I do not have a direct way to access any services offered under the api subdomain.
As I see it, I have three solutions:
Implement services that support the MVC site directly under the /services URI, eschewing consuming my own public API.
Create a super user in my membership store (where I know the username/password) that the site uses to access services in the api subdomain.
Change my authentication strategy.
It occurs to me that I probably should not utilize my own public API and would be better served using my own private services (which is ok because the logic is all shared via a facade layer).
What is the recommended strategy here? I also assume that if I were to utilize option 2 or 3, I would have to do so using JSONP. Is this correct?
Any advice would be greatly appreciated. And if more details are needed, please post and I will update with answers.
Thanks!
If Im following this correctly, you simply need to make sure your Forms Auth cookie is written with no subdomain so it would be: .example.com and if you are using separate servers, you share your machine key across them.
Since forms auth tokens are stateless and nothing is kept on the server side, this should work fine.
For simplicity and because I decided it was not in my best interest to consume my own public API, I implemented JsonResult actions on a new controller in the existing MVC site. This allowed me to utilize the existing forms authentication and avoid the cross-domain ajax requests.