I'm just starting my SignalR journey and don't seem able to find any information on automatic validation of input from clients such as seen in MVC & web api controllers!
Is there anything that I'm missing or is it back to good old manual checking?
Related
Ok, so I'm struggling a little bit with trying to get a authentication process in my ASP.NET MVC5 (Web API 2) project. To start, here are some requirements:
I can't use Entity Framework (all access to the DB needs to be done through stored procedures)
Needs to target .NET Framework 4.5.2
I am not using ASP.NET Core
I would like to be able to use Bearer (or similar) tokens for authentication
I would like to invalidate tokens if a user logs out or automatically invalidate them after 24 hours
I would like to pass (and receive) XML when sending requests to the "login" (or "token") endpoint (note that ideally the solution should respect the "Content-Type" and "Accepts" headers, so if I send it JSON it should respond in JSON, and if I send it XML it should respond in XML)
I will not be using external providers (e.g. Google) anytime soon (maybe never)
I would like to use the <Authorize> attributes to help with protecting other endpoints
I am using VB.NET, although answers to this question can be in C# (I can convert them or rewrite them to suit)
I would like to store the tokens in the database so I can record which user is doing what within the API
(note that there are lots of reasons why I can't change the above)
I've tried to do this with Owin (OAuth) but I've found the following issues when comparing this to the requirements:
I can't seem to send the token endpoint any XML
Responses from the authentication endpoints (both successful and unsuccessful) are in JSON
I can't invalidate the tokens when logging out
I am happy to move away from OAuth if that is the best way to go for what I want. I would prefer to use Microsoft built nuget packages (ie no third party solutions) or I'm happy to partially roll my own solution (I would like to leverage as much of in-built or Microsoft built code, including Identity and Claims as possible so I can minimise testing efforts).
I have read numerous StackOverflow questions about this and search heaps on the internet, but most articles stick with OAuth despite the above issues or they rely on EntityFramework. My current solution uses the code from here (pretty much copy/pasted with some custom code in ApplicationOAuthProvider.GrantResourceOwnerCredentials()): https://www.codeproject.com/Articles/1187872/Token-Based-Authentication-for-Web-API-where-Legac
Thanks for the help!
I did some more extensive research and it looks like OAuth is not applicable for my specific situation. Although it seems like a nice authentication method, I really need to invalidate tokens via the DB, and I need the API to always send/receive XML (these are apparently not applicable when using OAuth).
To solve these problems, I have rolled my own token-based solution that creates a hashed token on the client side, so I never send passwords over the wire (which is a little bit nicer) because the token is generated on the client side (note that I am controlling what happens on the client side - these are all in house clients and I am writing the libraries these clients will use). This involved me creating my own filter which inherits System.Web.Http.AuthorizeAttribute.
If anyone stumbles across this question and provides a really good answer, I'm more than happy to mark theirs as accepted.
I have built a Restful Web API for my (android) mobile application, and now i am trying to secure the access to the API. I was reading for about a week on this topic and i got the whole spectrum - from those who say that is is impossible to secure a Restful API to those who say that Https (SSL) is enough.
Here I don't want to start a discussion about that.I have settled with OAuth or OAuth2 it doesn't matter(as far as I have read OAuth seems to be the better choice, but in the Microsoft tutorials they use OAuth 2, so here i am quite confused), and yes i know that they are completely different, but I am so frustrated of searching that I would accept either (I must admit that I expceted this to be much easier). As I said, I was searching for about a week, and all I got are concepts(a lot of them). You send some data -magic start - usually username/password to the server, your data is being processed and you get a token back - magic stop-. On SO there are a lot of questions on this topic but most of the answers are unprecise (and unfortunately unusuable). For example I got this one How to secure WEB API, nice answers, but not really use of them, or this one Implement Web API with OAuth and a Single Page Application. I also got the examples from the Microsoft tutorials but there is a lot of overhead in the code and the part about OAuth isn't quite clear(which is unfortunate because the whole example should be about OAuth). I could post tons of links which claim to talk about this topic, but actually they are of no help.
What I am looking for is an simple, very very simple, example of an ASP.NET OAuth(2) implementation. It would be great if I just could use it with fiddler, provide an username/password in the header and with use of grant_type: xxx I get the token back(the permitted username/password can be hard coded inside the project, so no need for Entity framework implementation or any database on the backend). And it would also be great if someone could explain me how to use this token to authorize the user (I got it that I have to provide the Controller functions with the [Authorize] attribute, but how and where is this token-check being done ?). But please, don't post any theory about OAuth, I don't need that, here I am looking for the actual implementation of OAuth inside of Asp.Net Web Api
thanks
Here is detailed post about adding the resource owner password credentials flow for your Web API project.
The most simple implementation of OAuth2 in Web API project you can find here:
WebApiOAuth2 on GitHub
There are just two important files:
Startup.cs (with settings)
AuthorizationServerProvider.cs (authorization of users using oauth2)
I have spent days trying to get up to speed on this but everything has changed since I last touched a web project and I'm utterly overwhelmed right now, and getting nowhere. I'm trying to put together the pieces for an implicit grant flow - just a simple web API that respects the tokens issued by my local instance of I.S.
I have been able to download and configure I.S. v2 locally. I've got it issuing authentication tokens in JWT format after sending the browser to the login page. I can see the token info come back as part of the redirect URL from IS, like 'access_token=...&token_type=urn:ietf:params:oauth:token-type:jwt&expires_in=599'.
So now I need to configure my asp.net API site to accept these tokens, and I can't figure out how. As I said, I haven't done web work in a while so Owin, WIF, and many more things involved here are brand new to me all at once.
What are the key steps I need to do have my API site accept these tokens? I guess I'm not sure what packages to include, what goes into the web.config related to the WIF aspect, do I need to write any code to make it work, or should there be some combination of config settings that just activate it? Do I need to create a custom ClaimsAuhtorizationManager?
Please, I'm bad shape here, I've been looking at this stuff for days and I still don't know enough to even figure out what else to try. Every sample I've found has had a significant different from my situation, rendering it unhelpful to me (most point to Azure or ADFS, or use the old classes which are now deprecated). It's not for a lack of effort, I've been reading everything I can get my hands on and scouring the web for days.
Thanks in advance for any help.
IdSrv issues standard JWT tokens - so there is nothing specific to it.
You can e.g. use the JWT handler from Microsoft. For Web API v2 the typical way would be to use the JWT middleware - here is a sample:
https://github.com/thinktecture/Thinktecture.AuthorizationServer/blob/master/samples/Flows/ResourceServer%20(Web%20API%20v2)/App_Start/AuthConfig.cs
I am building a web site, and have created an API for it using WebAPI. The API is secured using OAuth v1 using DotNetOpenAuth and all is working fine with an iPhone app calling into the API. I would like to go back and make the pertinent parts of the web use the API too so that evrything always goes through the API.
The part I am slightly confused about though is if I make my website login go through the API, set up the web site as an OAuth Consumer, get an OAuth token for the current user, should I then in the web site code make a http call into WebAPI on the same box to call the API passing my OAuth token? (in the HTTP Auth header)
It seems like quite an inefficient way to get the web site to call the API as all calls require the server side to make a HTTP call as well, doesn't sound particularly scalable to me? I am not sure of the alternatives though given I want to use OAuth to secure the API.
This is a good question and keeps coming up (since you clearly realise the overhead of having another network-bound hop):
Do I need to consume my own API in my ASP.NET MVC or bypass API and go straight to the business logic?
I have tried to explain this in a blog post (towards the end of the post). However, in short: it depends. If your API and MVC site are part of the same application, then they sit next to each other as they are both the Presentation Layer - as I explain in the post. If, however, your API is the presentation layer of an SOA service and used by several clients including your MVC site, then yes it has to be separate.
In your case, I am inclined to put the MVC side by side your Web API - accessing the same business layer. And I believe this also fixes the OAuth issue you are having.
My company is considering working with another company on a particular module. Information would be sent back and forth between us through my web service. Thing is, my web service uses ASP.NET, and they use classic ASP. Everything I've found online says (it's a pain, but) they can communicate, but I'm not clear on some details.
Specifically, do I have to enable GET and POST on my web service? If I don't have to, but could, would enabling them make the communication significantly easier/better? And finally, GET and POST are disabled by default because of security. What are the security risks involved in enabling them?
My first question should be "Why use Soap?". The simplest common demoninator that you have between the two is XML so thats a given. However the choice of transport can be as simple as an single .ashx or as clever as WCF service.
Since your first consumer is using ASP why use a technology that makes it difficult for them?
The true bottom line here is what are your security requirements?