This is a question regarding ASP.net MVC 4. You can assume SSL throughout.
I have a Web API which will be available to clients over SSL using HTTP Basic Auth.
I also have a CMS, on the same domain, which uses the Web API via jQuery.
The user logs into the CMS over Forms auth.
For this reason I would like that it be possible to login to the Web API using either HTTP Basic Auth or Forms auth.
I plan to implement this using a custom AuthorizeAttribute, which will first check the basic auth header against the database if present. If the basic auth header is not present, then it will delegate authorization to the base AuthorizeAttribute to handle Forms auth.
First of all, is this a good idea? Can anyone see any problems in allowing either type of auth? Can anyone see any implementation problems?
First of all, is this a good idea?
Yes, it seems like a good idea and I do not see anything wrong with implementing 2 types of authentication mechanisms:
Forms authentication for users that are already authenticated on the same domain
Basic authentication for users that are not yet authenticated but posses a username and password and want to directly invoke some method of your Web API
Related
I'm confused on how the Web API implements the authentication?
I have gone through the links 1.
Link1
Link2
and need to summarize what I understood.
Owin katana is a mechanism that can be implemented for authorization.
There will be Iprincipal which can be created either in the host or
in the httpmodule which will be attached to the currentthread to
validate.
Token based authentication implements owin.
I have very little idea about the authentication mechanism in web api. If someone can help me to understand this, It would be great.
I have the following doubts.
Owin is a new way of authentication in MVC? or its already exists as
a part of windows and form based authentication?
If I wrote a module to authenticate what are the different ways I can use to authenticate an api method/controller?
The answer to your question could be quite big, I will try to give you some guidelines:
Katana is Microsoft's implementation of the OWIN standard
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana
Token based authorization is supported by OWIN and , therefore, by Katana.
There are two very usual ways to implement this token authorization, you can use Windows Authorization
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/enabling-windows-authentication-in-katana
or you can use a more standard and recommendable way using OAuth:
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
With ASP.net (netfx, not core), you use attributes on controller level to provide the metadata necessary to implement the authorization and authentication.
I have a setup of IdentityServer with configuration of a client with hybrid flow. Is it possible to have an ASP.NET MVC app to use this instance of IdentityServer to log-in the user without looping to IdentityServer's log-in page? That is, use a custom log-in page on the client side to get user credentials and then make a server-side connection with IdentityServer to do the authorization? Is there any sample that demonstrates this? Thanks!
From how I interpret your question, the Resource Owner Password Credential Flow seems to fit your scenario.
See the FAQ-like answer here.
"Q. Which Flow Types designed to be used ONLY in trusted environment (like backend REST API/ micro-services isolated from internet, or owned servers/devices, in general: trusted OAuth2 clients)?
A.
Resource Owner Password Credential Flow (ROPCF) [it involve human: app show its own login page then pass user/pass... to STS].
Client Credential flow [machine to machine (API to API): supply client-id and secret]."
*Disclaimer - I understand you are currently using Hybrid flow- My answer simply implies you could change your solution. If that is not possible, then I would suggest looking into multiple OAuth implementations for an MVC app.
Since I didn't get an answer for this, I'm just posting what I've found so far.
It looks like it is not possible to bypass the IdentityServer's log-in page.
For more info about IdentityServer flows see: OIDC and OAuth2 Flows
I am building an API and I'm stuck at the authentication part. I will try to explain what I have and what I'm trying to accomplish:
First, the API is closed to the public, it will only be used on the admin's back-end and for 3rd party devices in the company.
I have a model called Member that is being used with Devise for authentication
I'm also using STI to distinguish between 3 levels of users (using CanCan for roles)
What I thought:
I tried the Token authentication by Rails, it worked but I was afraid of expose the token in each Ajax request, I don't know if I was right.
I also tried to use a '/token' route to post my credentials and get a token, but I was facing the same problem in a more complicated approach. The link with the tutorial
I don't wanna use OAuth because it's unnecessary for that kind of application.
Is it secure to use this token authentication with ajax requests or is there a more secure way to prevent people accessing my API?
Token authentication needs to be done over a secure connection.
If for example you are using Heroku, it is possible to use
their credentials to gain a HTTPS url. With this the contents
will be encrypted and so exposing the token through JSON
over the API will be acceptable.
I am developing an ASP.NET MVC web application. The application is consuming a REST API, but authentication for REST-full application is quite unclear for me.
As REST is stateless, do I have to implement two different Authentications with two different databases, one for client, and one for the REST service?
Or, do I have to send the login/password each time, to authenticate on the server?
Please give me some advice or tutorial on this.
You can authenticate a Web API using individual user accounts that are stored in a database.
In this case client should obtain access token first. And then include it to each request, that requires authorization, header:
Authorization: Bearer boQtj0SCGz2GFGz[...]
Good tutorial can be found HERE
Also authentication methods could be extended in Startup.Auth.cs with Cookies or some external authentication methods (Google, Facebook etc)
The stateless isn't a main problem in your situation, problem is that browser can only send GET or POST request in tradition way in tag form, so to send PUT or DELETE request you should use Ajax, the easiest way is to use JQuery library and config it to send user credentials in http header(between requests it can be store in cookies) in every request and use basic-authentication if you plan use own auth logic. I recommned you to look some SPA frameworks like angularjs
or emberjs
or backbonejs
to simplify your life from hardcode JavaScript . Also in future you can easy extend your auth by OAUTH 2.0.
I've been reading different articles on the subject of securing WebAPI, including:
leastprivilege article
kevin junghans article
piotr walat's article
and many others.
I would like to use the MVC 4.NET SPA template (with either Backbone.js or another JS lib) and I'd like to secure WebAPI used by SPA with basic http authentication, using tokens in the headers because some of the WebAPI clients will not support cookies required by forms authentication.
The SPA template uses SimpleMembership and oauth, which I would like to use and combine with basic http authentication.
What's unclear to me is whether the SPA template out-of-the-box authenticate and authorize WebAPI with basic HTTP authentication and tokens, or do I have to follow and piece this together from the links above?
This is quite a large topic and its best to completely understand it before simply plugging in templates.
Here is a great video to help put everything in place: https://vimeo.com/43603474
You must be using SSL for any token based authentication (like oAuth)
Once the user is authenticated - via oAuth or your own membership provider, you can simply attribute any Web Api methods with [Authorize] to ensure that a non-authenticated user can't call those methods (will return a 401 - not authorized if not authenticated)