I'm being confused by the custom authorization in MVC4.
I have implemented a custom security attribute (based on System.Web.Mvc.AuthorizeAttribute) that worked fine and now I started to extend my project with a web api. However, it seems that the web api needs to use the System.Web.Http.AuthorizeAttribute (?).
Can't I use the same authorization for both web api and standard mvc pages?
Simply said: no you cannot. The systems were made seperatly. It might be possible that Microsoft will merge these in the future.
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.
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 developed a website in ASP.NET MVC 4 using NHibernate, now I need to perform an integration with the site using Windows Forms.
How can I perform authentication system using the same users?
What technology should I use? Web API, SOAP or Rest?
Thanks!
Small clarification of terms : REST is an architectural style, SOAP is a protocol for exchanging information, and Web API is a framework to build HTTP Services.
The stock answer for questions like this is "It depends"
Before you continue with a technology selection, currently is your method for authenticating users separated properly from your business/presentation logic?
If that is the case, being that you are using MVC 4, Web API may be the path of least resistance, you can put all of the functionality that requires authentication behind Web API calls. And your controllers will call them. Once that is done, a Windows forms app can consume the data in a similar way.
I saw that ASP.Net MVC4 WebApi exposes services as a Rest ones.
But what is actually the difference between normal Rest and ASP.Net MVC4 WebApi?
I'm not sure what you mean by normal Rest.
REST is a paradigm.
HTTP is a protocol that follows that paradigm.
ASP.NET Web API allows developers to write ASP.NET applications that can be accessed via HTTP and adhere to the REST paradigm. While you could create a REST API without Web API, Web API provides a ton of features that will remove a lot of the pain associated with creating a truly RESTful API in ASP.NET.
apigee has many great resources for REST API best practicies.
Are you asking about the general REST standard or the way that REST has been done traditionally on the Microsoft platform prior to the MVC4 Web API? I am thinking you are approaching this as the second one.
The updated approach in MVC4 gives you more REST capabilities without the WCF model. Here is a recent post on the subject: http://mattmilner.com/Milner/Blog/post/2012/02/28/WebAPI-or-WCF.aspx.