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.
Related
I am implementing OIDC/OAuth authentication & authorization in a classic ASP.net MVC application using OWIN. For API calls that are not supported by Microsoft's OIDC middleware, it appears that I have some choices.
I can craft and make rest request directly to the IdP.
I can use classes contained within System.IdentityModel.
I can use classes contained within Microsoft.IdentityModel.
I can install and use IdentityModel built by Dominick Baier and Brock Allen
There may be other choices too. Among the above, it appears that IdentityModel by Dominick and Brock is the most mature, advanced and complete.
Given that I am using classic ASP.net MVC with OWIN, should I favor one method over the other or will I need to use a combination of the above? Where would I use one over the other? What would be some pros and cons?
I know there are some older posts comparing System.IdentityModel with Microsoft.IdentityModel, but I more interested in what's best in 2020. :-)
Mark
IDENTITY MODEL
For C# the IdentityModel HttpClient extension methods provide a nice facade over OAuth messages, as in this example class of mine.
SYSTEM.IDENTITYMODEL
This has some classes you can use in a Server Side web app, eg for claims / principals.
MICROSOFT.IDENTITYMODEL
This mostly contains old / redundant WS-Federation stuff and is best ignored.
OWIN
This does cookie handling for server side web apps in addition to handling OAuth / OIDC messages. IdentityModel is more token based than cookie based.
SINGLE PAGE APPS
My personal preference these days is to develop Single Page Apps. In this setup I would use IdentityModel libraries if building C# APIs.
SUMMARY
I would definitely use the IdentityModel Client library for the extra requests you refer to.I don't think it will do cookie issuing though, so maybe continue to use OWIN Openid Connect for that.
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 am starting a new product that will require a .NET based server (using WCF) hosted on Azure. I would like to have basic authentication and security features. The clients are all "rich" UI but are not neccessarily microsoft ones.
We intend to have the first client application written in Silverlight, but we want to keep our options open to implement clients for iOS and Android in the future. So we do not want to use WCF specific features but rather protocols that are easily available on other enviroments.
Of course, with the Silverlight client, we hope to get as much done for us automatically as possible. We intend to only communicate through web services.
Which bindings are recommended for such a scenario?
How would you implement security? (assuming we need basic security - Users being able to log in with encrypted user and password and perhaps some built in basic role management althouh this is optional).
Suggestions?
You could use WCF to implement a REST interface
The binding would have to be a basicHttpBinding (to be open to all platforms) and using SSL to secure the line.
Managing credentials could be done using tokens to be passed back and forth after authentication. Much like a http session. You could pass the token using a cookie but the token could be part of the API or Headers as well. See this Best Practices for securing a REST API / web service
This would grant you the power of .NET and WCF without losing interopability.
I have a website developed using ASP.NET MVC3.
I now want to expose a REST API for others to use which will expose the same features as the website.
In the website, once a user has logged in and credentials validated against a DB, the session manages the logged-in state of the user.
How would I do the equivalent with the REST API, where many of the methods exposed require the user to be logged in (or at least have valid username and password)?
In addition to this, would the best approach for the website be to use the REST API also (presuming the API covers all the functionality required by the site)?
How well is ASP.NET MVC3 suited for this - of course taking into account that the site already exists using this framework?
I wrote up a blog post on how to [Build a RESTful API architecture within an ASP.NET MVC 3 application] years ago and ended up having to let the site go. :( It might be a good start if you want to take on building the REST API into your MVC application.
See answer by #tugberk on using WebAPI for a good solution.
ASP.NET MVC is very well suited for this. Although you can use other approaches (like WCF) I would stick with MVC since you already have a working site that needs to be exposed for other consumers.
See also my other answer:
Which is better for building an API for my website: MVC or Ado.net data services?
Note:
WCF Web API is now ASP.NET Web API and has changed a lot. The beta
version is now available. For more information: Getting Started With
ASP.NET Web API - Tutorials, Videos, Samples
I would go with WCF Web Api to do that. ASP.NET MVC is also nice and capable of exposing your data but WCF Web Api is more capable if you consider exposing your data to your users. It is easy to use and integrate REST Web APIs to your system.
For the authentication, API Key is always the best way for this type of scenario. Here is a good example on how you can implement API Auth with WCF Web API :
http://weblogs.asp.net/cibrax/archive/2011/04/15/http-message-channels-in-wcf-web-apis-preview-4.aspx
Note:
They just released the preview version 5 couple of weeks ago and
Message Channels has been changed to Message Handlers as far as I
know. But the above article should give you an idea.
For security implementations, the below might help as well :
wcf Authentication Token Implementation - How to do
ASP .NET MVC is a great choice for this. I have created several ASP MVC that act as RESTful services as well as websites.
To summarize the design paradigm I use, each controller has an action that emits a JSON representation of the requested data. Said data is loaded in a view model on the server, and the built in JSON serializer takes care of the server side, while a jQuery view nicely loads the data back in for my actual webpages to consume.
The site itself has index actions on each controller that emit that necessary markup, but not the data. jQuery document.ready methods on the pages load in the data from what is essentially my rest api, but build right into the site.
Checkout Nerd Dinner for great sample code. http://nerddinner.com/
Concerning security, I think my experience will differ from yours. ASP MVC integrates very nicely with active directory if your users are all in the same domain and have AD credentials. This is the only method I have used, and with ease, success, and satisfaction.
I have had coworkers interact with other APIs that hand out a token upon calling an authorize method. The received token would then be the clients responsibility to store and hand back on each request, but I cannot talk you through implementation details, as I have not person experience on that front.
I would go with a WCF web service based implementation as follows.
Wrap all your business logic into a separate dll project named as yourproject.businessservices for example
Create a authentication webservice which will generate a non-repeatable token per user login
This login stores the essential details of the user along with the token in a Cache like MemCache which should have a sliding expiration
If the user has not accessed the cache for let's say an hour, the cache expires and the user is logged out
If the user is using it the cache keeps getting extended.
On the wcf services side,
Create APIs to return the token on authentication
All the wcf methods will have this session id which needs to be validated
The advantage is that the wcf methods can be exposed to return xml or json format and can also be used as normal web services.
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Xml, BodyStyle = WebMessageBodyStyle.Bare, UriTemplate = "/MyModule/XML/GetData/{customerSessionId}")]
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "/MyModule/JSON/GetData/{customerSessionId}")]
I am in the process of re-writing some very outdated .NET 2.0 SOAP web services for my company. So I am rewriting them using MVC3 RESTful. This method would simplify the usage of our services for our client base (over 500 clients using our current SOAP services) who are on multiple platforms and languages.
I am looking for a BETTER method of authorization for the RESTful services, than what the previous developer used for our .NET 2.0 SOAP web services (he basically just had the client pass in a GUID as a parameter and matched it in code behind).
I have looked into oAuth and I want to use it, HOWEVER, I have been told, from my superiors, that this method is TOO complicated for the "level" of clients that connect to our services and want me to find another simpler way for them to connect but still have authorization. Most of our clients have BASIC to no knowledge of programming (either we helped them get their connection setup OR they hired some kid to do it for them). This is another reason that the superiors want a different method, because we can't have all 500+ (plus 5-10 new clients a day) asking for help on how to implement oAuth.
So, is there another way to secure the MVC3 services other than passing a preset GUID?
I have looked into using Windows Authentication on the services site, but is this really logical for 500+ clients to use?
Is there an easy and secure method of authorizing multiple users on multiple platforms to use the MVC3 RESTful services that a end-client can implement very easily?
Thanks.
If you don't want anything too complicated, have a look at Basic HTTP Authentication. If you use it over SSL then it should be safe enough and also easy enough to implement for your clients. The Twitter API actually used this up until a few months ago when they switched to OAuth.
You want to distinguish between authentication and authorization. What you are looking for is authentication and indeed as Caps suggests, the easiest way may be to use HTTP BASIC authentication along with SSL to make the password is not compromised.
You could look into other means of authentication e.g. DIGEST or more advanced using ADFS or SAML (ADFS could be compelling since you're in .NET). Have a look at OpenID Connect too - it is strongly supported by Google and has great support.
Once you are done with that, you may want to consider authorization - if you need it that is - to control what a given client can do on a given resource / item / record. For that you can use claims-based authorization as provided in the .NET framework or if you need finer-grained authorization, look into XACML.
OAuth wouldn't really solve your issue since OAuth is about delegation of authorization i.e. I let Twitter write to my Facebook account on my behalf.
HTH