As of right now, I have the user register/log in and then if successful, redirect them to the homepage. However, this is extremely artificial as the user can simply type the url and go to any page they want. I'm fairly new to this and I've heard forms authentication mentioned multiple times as a way to do what I need: a simple means to prevent a user from accessing any page and once they haven't done a "Request" in awhile, I want them to be "logged out" and sent back to the log in page. I guess, in the end, I have three questions:
1) Can someone provide me a link to a great tutorial on authentication? I don't want to get too far in depth if I can avoid it.
2) Also, is it recommended to use cookies for this or not? I've heard different views on this?
3) I was told I can set this up in the web.config as well as in code behind? Is this true? If so, which do you recommend?
Thank you very much and I apologize for the broad question(s). If you need any more information, please let me know.
Here is Walkthrough: Creating a Website with Membership and User Logon that you can use.
As far as using cookies is concerned, they can be exploited. To be safe, its best not to put anything of value in them. If you have to, then you should secure them (another topic all together). In the scope of your question, know that ASP.NET encodes and hashes its authorization ticket so you are ok using the default cookie settings. More info on the Web.config form element attributes here.
Forms Authentication is setup in the Web.config file. You can set the slidingExpiration attribute to log a user out if they haven't made a request with in the time set in the attribute.
Take a look at this MSDN tutorial:
http://msdn.microsoft.com/en-us/library/ie/xdt4thhy.aspx
You can use the builtin asp.net sql membershiprovider and login controls for register and login this is implemented in the default web application project.
Then you can check the value of Request.IsAuthenticated in page load and redirect to login page with Response.Redirect(loginPageUrl)
1) http://www.asp.net/web-forms/overview/security good place to start.
2) If you are using the ASP.NET builtin authentication in most scenarios you dont have to worry about cookies. IMO nothing wrong with cookies :)
3) Usually you have to set this up in both. Generally you configure the auth method and the providers in web.config and do the redirection to login page in the codebehind or globally in global.asax.cs
Hope this helps.
Check How to: Implement Simple Forms Authentication.
This type of authentication requires a log-in form referenced in web.config. It can be done with or without cookie: Cookieless Forms Authentication.
Related
Ok so I think I've settled on choosing BLAZOR for my upcoming project. But first I need to do something that is seemingly very basic.
For context, Blazor Server side will be how I interface with my SQL Server dB, I want "individual accounts" mode to be the way users authenticate. I'm using net 6.0,almost all tutorials out there seem to be net 5 since they all still have startup.cs files. Ok, but I also am creating a parallel app that is NOT a website, but I want it to grab data from the same database via routes after authenticating.
For example, website.com/api/data?variablestograb as a GET would send me some json data.
OK that being said, how do I login programmatically from an outside app? If you must know, the outside app is part of Unity C#. But that doesn't matter so much, what itll do is use a post call to login in via the api routes. Something like
Website.com/api/login?un=blah&pw=haha
This will generate a cookie and I can grab it with the session data and I'll use this with every get call hence.
Just using the basic templates, Blazor server net 6.0 with individual auth, how do I set up such a route? Looking at the files, I'm at a complete loss on how the login pages are actually passing data around.
Thanks!
Update: the specific ask is exactly how do I modify the Blazor Server Net 6 Individual Accounts template to allow me to authenticate a user via an external access api? My thought would be to reference the route above for /login/ but that might not even be the best practice. But even if it is, how exactly and where would I update the template to make this happen?
(I have a feeling it's pretty basic to do, but I've been reading tutorials for weeks now and they're all just talking about internal authentication and verification within each Blazor component. I basically want an external program to also be able to "drive the car" remotely, but first it must authenticate.)
If you're building an API for this from scratch, then it seems like you have the right idea, no matter what happens, you're going to send the cookie to be website every request or at least a session id which contains all the information provided. From a database perspective maybe create a session table which then contains all the info you want and also can be easily found. That's a way for you to create a cookie for client server communication, however this is from my limited knowledge and may not be the best way.
I'd recommend hiding information like keys in the header to prevent exposure, looking at other APIs like the Spotify API you can see they set the authorisation bearer.
Exposing all the information for the credentials in the URL for what could be sensitive database behaviour may not be the best. You can hide the information in the header for every request you make.
Maybe have a default controller that obtains the user information before handling any specific requests and making it accessible to your other methods/requests?
The basic process for any external authentication is:
Redirect to the external log in page.
External Provider does it business.
External provider posts to a page on your site with the authentication information included - normally security info in the header or a cookie.
The Blazor app reads the authentication information with the AuthenticationStateProvider.
Normally you just need to write a customer AuthenticationStateProvider and code to redirect if the user is not authorized. This may be a manual button in the top bar, a you aren't logged in page with a button to log in, or an automatic redirect to the provider. The return for the provider is either your landing page or some other page to tell them they logged in successfully.
The custom AuthenticationStateProvider replaces the standard one in DI services and provides the security information to the Authorization components.
Search for "blazor custom authentication provider" will get you lots of good resources.
I have an ASP .NET application which has a number of aspx pages. These pages were not having any login or session management features and any user could directly type the url and visit any page.
Now I want to add state management feature to all the pages. I created a new signup and a basic login page which accepts username and password and has necessary database for it. It is fine to use any server or client state management features, but how can I implement it with very minimum code changes.
One straight forward solution here is to implement session variable in server side to store logged in user details and check for it in the Page_Load event handler of each and every page. But here, code change has to be made in all the pages and I don't want that as there are so many pages. Any easier way will help.
Any ideas please??
Well, first of all it was good that you haven't implemented authentication in Page_Load on every page. Whenever approach you think of requires that you copy-paste code in multiple places - you are doing something wrong.
That being said, you will probably need to create base class for your Pages and by doing that you could have authentication restricted to one spot / class.
However, it would be better if you combine that with what ASP.NET framework offers. From stuff you are talking about it seems you are using ASP.NET Forms - here is article that should provide you with fine overview on everything you need to do:
How to modify web.config to use Forms authentication
Login and Logout user (create authentication cookie)
Necessary code for authenticating requests that needs to be added to Global.asx
Restricting access to pages by entering appropriate values in web.config (although better approach would be with base class I mentioned)
Role-based Security with Forms Authentication
I'm new to C# and ASP.NET (not MVC) and trying to code a web site.
Here is the question:
Which is the best approach for Login, Authorization and Session management? I'm not asking for how to use built-in membership classes or another ready-to-use solutions. I'm merely asking for a manual approach or methodology.
After a member writes User Name and Password and clicks submit button; which do you think is the best solution to keep user logged while he\she browses pages, clicks buttons or somehow interacts with the web site
E.g is it a good method to use Session and write the User Name, Id etc. to session and read the session in every page request to check if there's any member information; if so, set the page layouts according to member's preferences?
Or creating an object in login, setting it's properties according to logged in user and using same object for entire session and destroying it with logging out?
Thx
I suggest that the best approach is to use a pre-exisitng solution that has proven realiable.
For authentication, use a MemberShipProvider. If you don't want to use for instance the SqlMembershipProvider, feel free to implement your own by deriving from System.Web.Security.MembershipProvider. Then register you custom provider in the web.config file of your application.
To get started, just search the web for "build a custom membership provider" and you will find lots of tutorials.
For authorization, use the possibilities provided by the <authorization>...</authorization> section in web.config. Make sure to learn about the possibility of placing additional web.config files in sub folders of your application.
If you need role based authorization, use a RoleProvider. Related web search: "build a custom role provider".
If you want to allow your users to store preferences, use a ProfileProvider.
In short, resist the temptation of reinventing the wheel...
I'm enabling an windows identity foundation on an existing webapp.
I want to mess as little as possile with the existing code so I would like to the login page which uses formsauthentication left in the application and I just connect with the STS if the user enters the application via a specific page e.g "im_comming_from_some_other_site.aspx".
in the "im_comming_from_some_other_site.aspx" the code would be like:
Page_Load(...)
{
if(verifyAgainstSTS()
{
FormsAuthentication.SetAuthCookie(<some_STS_Userid), ...)
Response.Redirect("default.aspx")
}
else
{
Response.Redirect("http://<STS_server_name/<STS_service...etc>")
}
}
Is there someone who knows if this may be done and how? Any links to example code (if available) deeply appreciated.
(Of course some code would be needed when to determine what to do when the authentication is timed out; either go to local login page or goto STS-login page)
I know this may seem like a bad design, not going all the way with STS, but I need to implement this ASAP and I want to keep the original site as untouched as possible.
It is not a bad design, it's your requirement and you try to fulfill it. We have working system built like that and it's not a rocket science. The only difference is that we switch it to forms/sam statically (via global settings), not dynamically.
Anyway, you keep your forms authentication in web.config so that when there's no authorization for current user, forms redirects the request to the login page.
In the login page you have two options. One creates the forms cookie somehow.
The other option involves WIF's FederatedPassiveSignIn control.
If a user follows forms authentication, the cookie is set and you are done.
If a user follows the STS login control, sooner or later he/she will come back with valid SAML token. The FederatedPassiveSignIn will pick it up automatically and you just handle the redirect in the SignedIn event.
You will even not need the if you mention in your question.
There's one caveat from what I remember. When a user is authenticated by STS, the WS-Federation cookie is created, you can read claims etc. Everything works.
However, if a user is authenticated by forms, the SAM (SessionAuthenticationModule) will REPLACE forms cookie by the WS-Federation cookie in ASP.NET pipeline upon EACH request (I guess it's because the SAM is later in the pipeline that forms authentication module).
This will NOT blow up your context.User.Identity.IsInRole(...) also authorization works correctly because SAM will copy user roles to corresponding claims.
However, if at any place in your code you try to extract information directly from the forms cookie (instead of using general APIs), you could find out that the forms cookie is not present even if the user was authenticated by forms in first place (and the cookie is not present because it will be replaced by the WS-Federation cookie).
I need to use custom authorization mechanism. Its very simple, uses database in which something like session is stored and checked if its active according to cookies. Nothing special. What is the best way to control permission to each side. Of course I can check in load event on each site if user is logged in but is there any other way?
The built-in mechanism is ASP .NET Membership, which should fit basic needs out of the box. (If it does not you should try explaining why you cannot use it - there may be a solution).