Problem description
All the routes (URL(s)) for the API (including parameters to use) are accessible to unauthenticated users by calling this API AbpServiceProxies/GetAll which doesn't require any token and is not protected.
This opens the application for easy attacks.
Can you please tell me how to secure this API without affecting the normal functionality of the framework.
Abp package version: 7.4 (last version at the time of writing this issue).
Base framework: .Net Core.
Steps needed to reproduce the problem: Just call the API like https://ServerIP/AbpServiceProxies/GetAll
I expect to find a way to secure this API or if it was not possible, at least list only public APIs which has no [Authorize] attribute.
Related
As shown in https://petstore.swagger.io/, apis of the PET controller get authenticated by OAuth2, but that of the STORE controller, gets authenticated by ApiKey.
I want to achieve the same using IOperationFilter in .Net MVC (and not .Net Core).
Though I am able to turn on the BasicAuth for one API, but couldn't turn off the ApiKey Auth for the same. May be I am not able to find the correct documentation of using the tool.
Could someone point me towards the correct documentation please.
Swagger-Net version 8.3.35.101
I'm using identity server 4 as an authentication server, and have successfully demonstrated authenticating clients for access to my MVC web application and my Web API application, both running on IIS under .NET 4.7.
The problem I'm having is finding the correct approach for ensuring clients are only able to access the endpoints they should after the authentication process. EG, I have two clients, one with a write scope, and one without. How do I ensure the one without is only able to access endpoints that will read my data and not amend it?
The best method I've found so far is to use an authorization attribute like this:
https://github.com/IdentityModel/Thinktecture.IdentityModel/blob/master/source/WebApi/ScopeAuthorizeAttribute.cs
However, this is marked as obsolete and I'm unaware of the version based on OWIN middleware is mentions. Considering my MVC and Web Api applications are unable to be updated to .NET core applications, what would be the best approach?
Since the scope claims are available within the ASP.Net pipeline you can implement your own access control filter quite easily. It may be that that particular library is obsolete but the practice of enforcing scope in an MVC/WebAPI filter is certainly entirely valid.
Background:
I've implemented a Web-API (.NET), now I need to do the most important thing,
Secure it.
As I investigate this topic I understand that the common way is the Bearer Token.
Now we getting to my problem.
My Problem
On one side:
Every article I saw (that explains the concept and the way to implement it over .NET) starts from a project with a Web API template that holds MVC and Web API and in the authentication field choose one option from Individual / Organizational / Windows .
On the other side:
I don't need a MVC project, I need only Web API (without any GUI) that the reason I choose the empty project and check the Web API checkbox, in that way I cant choose an authentication type, I forced to start with no authentication.
Questions:
1.Do I bound to use MVC to get authentication ? if not how can I do it from pure Web API project ?
2.Maybe I will create an Authentication Server (that only generates tokens) from that Web API template (with the possibility of choosing authentication type) ? (and use the token on the real Web API)
3.There is any benefits of implement the Authentication Server on a different project and on different server ? (Kerberos style )
P.S I want to use an out of the box solution because the security aspect is the most important one (to my opinion) and should be flawless.
I wrote a blog on this topic called 'Securing and securely calling Web API and [Authorize]': http://blogs.msdn.com/b/martinkearn/archive/2015/03/25/securing-and-working-securely-with-web-api.aspx. I think if you read this, you'll have all your answers.
The Web API template does include MVC by default so that you get the automated docs feature (which is a great feature to have). However the authentication part is related to a core ASP.net feature, not specific to MVC or Web API. You'll need to enable one of the authentication options to secure your API using .net's built in security features.
If you do not want the MVC project that comes with Web API, just delete it after the project has been created. It is contained within the 'areas' folder. If you delete that folder, you'll be running on pure web api.
To answer your specific questions:
1) No you do not need an MVC project to secure an API project. You can use the [Authorize] attribute on your API controllers and actions.
2) an authentication server gets created by default with the web api template. You can access it and get tokens via http:///Token
3) No, you need to use the api itself to serve valid tokens for secured controller/action requests
Hope that helps. If not, then please be a bit more specific with your questions.
I have searched for this answer but haven't found anything and need help with the concept. So, we created an API with rails which feeds our Angular web app (separate server) and our iphone app. Currently people login through the form and devise from the api sends an auth_token for future interaction, the data is also secured using AWS keys.
Now we want to open up the API to the public, but only on certain subscription plans and maybe only part of the functionality. We want to use authentication similar to Pingdom were a user on the correct plan generates an api token within their account and sends this token with the request. This is where i'm at a bit of a loss, because if i secure the controllers of the API for some users who authenticate by token then this will effect the iphone and web app users too who don't have an api token?
I can not get my head around the concept of a private API which is available to some users if they have an api key. Please help.
It may help to think of your private and public APIs as not-necessarily-compatible versions of the same API. It's the same principle as introducing a v2 API that breaks backwards compatibility with v1, but needing to support both versions.
Obviously you wouldn't want your internal API to share a version numbering sequence with your external one. But there are various gems that will help you with handling versioned APIs, and that could include differences in authentication methods.
So the API that's available to your users could look, to them, like it's the only API available. It could have its own version numbering system, so that if you decide to introduce v2 of your public API you can. But the same system that maintains that API could do something similar for your "internal" API, ensuring that its endpoints are separate from the public ones, but allowing you to share common code between public and private implementations in the same way that a v1 and v2 API might share some code but would also have differences.
I'm mildly familiar with DotNetOpenAuth and OAuth in general, but in terms of Web API development, what is the best way to lock down a web service in terms of the following criteria:
Ease of implementation
Interoperability/compatibility with end-user facing platforms (iOS, Android, Win Phone, Flex...)
Whether or not it is clearly standards-based (like OAuth for example)
Thanks!
please take a look here: OAuth 2.0 in Web API
Inside the WebApiContrib project there are also Basic Authentication samples which is straight forward but it should not be used without SSL.
The DotNetOpenAuth .zip download includes a sample WCF service that is protected by OAuth.
There are a couple of wcf web api implementation to handle authentication on internet. I have done one as well # http://misaxionsoftware.wordpress.com/2011/07/29/secure-restful-web-service-by-wcf-web-api-no-https-seriously/
Note: code is based on Preview 3, some class name has changed in Preview 5.
The idea of implementation is ensure secured communication without SSL.
It's easy to construct. The function is transparent to your service because all the work is done in message handler. You don't bother to call the authenticate function in your service method.
Compatible with end-point where RSA encryption is supported.
Standards-based, hmm... Standards varies from case to case...