I'm working on a solution to part of my companys site that is done in 2 different languages. My part of the project is in ASP.NET, and the login portal is in a different language.
We pass authentication credentials by storing login information in the database on the portal page and then sending a corresponding token to the URL in the page written in .NET. Almost all the tutorials and articles I've read about security for ASP.NET, and most languages, the message has generally been "just use the built in stuff and don't mess with it".
I have code that takes the token, goes into the database and gets the user details.. what do I do then to integrate that into the built-in security stuff for ASP.NET? I'd like to ultimately use Action Filters for authorization on my controllers. Thanks.
Once you get the user details you could emit an authentication cookie:
FormsAuthentication.SetAuthCookie("username", false);
This will append a cookie to the response so now the user will be authenticated and you can safely redirect to a controller action decorated with the [Authorize] attribute.
Related
In "old" ASP.NET I could build a custom authorize attribute and override HandleUnauthorizedRequest. I cannot seem to do this with ASP.NET Core using a custom authorization handler. The latter either "succeed" or "fails" and I would like to redirect to alternative controller actions based on the nature of the failure.
Here's the scenario. Users of my web app have a claim which indicates that they are "active" users, i.e. they have fully registered and we have validated their details etc. New users have been authenticated using the OpenIdConnect middleware but, until we have fully validated and set up their account, do not have the "active" user claim. Thus, both new users and active users have been authenticated. I want to prevent new users accessing most of the application. Every time they try to get to https://app.example.com/dashboard I want to redirect them to a https://app.example.com/newuser page, from which they can go through the set up process.
I can use an authorization policy on my controllers to check for the presence of the "active" user claim and allow access. When a new user doesn't have this claim, and fails the authorization, I want the authorization handler to have some logic which then redirects them to an area of the app which they do have access to. But I cannot see how to do this using the authorization framework in ASPNET core.
There is a somewhat clunky solution which uses the CookieMiddleware and implements a handler for the OnRedirectToAccessDenied event - see https://github.com/aspnet/Mvc/issues/4890. I also thought about implementing an action filter which runs on every request.
Am I just being stupid here? Surely, it makes sense to want to carry out some action on authorization failures which doesn't just send the user off to re-authenticate.
After some digging about and referring to the wonderful book, Pro ASP.NET Core MVC (6th Edition, Adam Freeman), the simple answer to my question is to create an Authorization Filter. This implements IAuthorizationFilter with a single method OnAuthorization(AuthorizationFilterContext context). In this method do whatever you need to do to check the request. If it fails authorization simply set the context.Result property to some IActionResult, in my case RedirectToActionResult. If the request passes authorization do nothing.
You can also use dependency injection in the filter - fantastic.
There is no mention on how to implement or code samples for IAuthorizationFilter on the Microsoft ASP.NET docs site. Thanks are to Adam Freeman.
I use MVC5 for a site where users have to login with custom credentials. I've changed the login procedure from the inital auto-generated code to a somewhat single page approach.
Users enter their credentials
these are sent via ajax to the controller
if the credentials are valid, a loading animation shows and the main page is being loaded via ajax
the controller that returns the main page is annotated with the [Authorize] attribute.
I wonder: is there something basic that speaks against such an approach?. The site I run does not have any top secret contents, but it should not have a backdoor just because I missed something basic here.
From what I could see, MVC5's auto-generated login procedure sents the credentials in plain text as well, just like the ajax post I use. The auto-generated login includes a RequestVerificationToken which I obmitted.
Thanks for any ideas!
Using AJAX to authenticate a user is a common approach. A couple things I would recommend:
Whenever you are sending credentials like a username/password combination it should always be done via SSL. Even after the user is authenticated all requests should be send over SSL to prevent a hacker from stealing the security token.
Make sure that there are is no UI code in your AJAX calls. AJAX is used for sending and retrieving data only. Your UI should be on the client using a framework such as Knockout, Backbone, or Angular. Even if you are not doing a full blown SPA (Single Page Application) and do not require one of those frameworks, select a client side templating framework like Mustache or Handlebars.
I have built a SPA application with Hot Towel (durandal) and I have problems to understand the authentication.
When I am loading data from my database how can I filter this data to the current logged in userid ?
thanks for help,
Best Reguards
If your SPA is calling asp.net of any kind on the back end you can still use Forms Auth cookies to secure your ajax endpoints and identify the user making the request. Depending on how SPA like you need it you can just use a standard aspx or mvc login page, then from there redirect the user to your SPA start page that calls your main.js and starts your SPA. All ajax calls you make to that site will have the Forms Auth cookie set and you can use it to verify the user making the request. Here is a link to standard forms auth. If you want handle the login process in durandal as well that can still be done, you just need to make your ajax endpoints for logging in and out to allow anonymous and then handle setting the forms auth cookie in them.
On the server-side, referencing User.Identity in the controller will get you the properties of the currently authenticated user. The question is, what form of authentication does your application use (Windows, Forms, Basic, Anonymous, etc.)?
I have an asp.net application in which I have used forms authentication.
Now, there is a need that user authentication is done outside of my application.
There will be an intro page which will do needed authentication.
Then, after authentication is successful user should be redirected to my app.
Of course, if user is not authenticated via that external page and tries to access my app directly, I need to redirect him back to this external log in page.
What's the best way to implement such a functionality? One way which I think is feasible is that I transfer some particular encrypted string in cookie from external login page and verify it in my application. So, based on that, I can see if user is authenticated via this external page or not.
Your own suggestion of validating the external site's cookie is how I would implement this functionality as well.
I would simply go with adding a Webservice in the first application that you in your stage can connect to a check if the user is logged in, the only problem with this is that you need to know which user whants access to your site and also to confirm that this is truly that user (So a user cant use other users who are logged in). This info could probably be sent via a cookie.
You probably should no be rolling your own single sign on solution in 2011. Rather, you should look at some emerging standards -- particularly OAuth and OpenID. Getting rolling with them is easy -- check out the OpenID website template on MSDN.
At the end we decided to use SAML 2.0 protocol.
External login page posts SAML complient XML digitally signed with certificate to other application. In this XML authenticated username is transferred. Application which receives this XML verifies digital signature with certificate's public key, and if validation is OK, reads username from XML, applies internal application authorization logic and at the end creates auth. cookie. We will probably add encryption so data protection would be complete.
Here's the situation, I've got a console application that needs to run once a day and make a few requests to pages that require authentication to view. The pages are hosted in a really basic ASP.Net Web Application.
So, I know that in order for the requests to go through successfully I have to authenticate with the server. So I've hooked up the console application to the ASP.Net Membership Provider I'm using for the web app and it successfully determines if a set of a credentials are valid. However, after calling Membership.ValidateUser() any requests I make just get the login screen. After doing some reading it seems that this is because I'm missing the important cookie information that persists my login or what-have-you.
I'm using a basic WebClient to make the requests and then reading/discarding the result.
So the meat of the question is this: Is there a simple way to validate the login information and hold on to it so that I can make the requests successfully, or is this the exact same case as the other two questions I found that require the WebClient to make a "manual" login request to the login.aspx page and try to hold on to the cookie from there?
The questions I'm referencing are:
Authenticating ASP.NET MVC user from a WPF application
and
Login to website and use cookie to get source for another page
With FormsAuthentication the webserver has to generate a Forms Authentication Ticket for you. The best (only?) way to do this is to log into the site, so I'd just log in like the other questions.
If the intent is to send data to the server and/or get data from the server, then the most logical architecture is probably to create a web service using either ASMX or WCF. Then configure the service to use a security token, such as a username token or a SAML token. This will make the client less likely to break when the server code changes its data model.
Otherwise, if you wish to use only a basic WebClient, then you will have to find a way to pass your credentials to the login page and retain the login cookie that is returned from the login request. Then, make sure that the login cookie is included on all subsequent requets, similar to the Stack Overflow question that you referenced, "Login to website and use cookie to get source for another page".