In the following code where the creating user accounts(userid, password) stores in?
FormsAuthentication.SetAuthCookie(RegisterUser.UserName, false /* createPersistentCookie */);
Sameway, When LogIn, how it works?..(i.e)How the values are retrieved and compared to the data we are typing in the login page(userid, password)..Please explain the process..I am having doubt whether it is storted in ASPNETDB.MDF - > aspnet_Membership..If the values are stored here, then how application works when retrieving values from here to compare the data we typed in the form..Here the application I mean is Sample Application present in .NET4.0(Visual Studio 2010)..Pls help..
UPDATE: 24/12/2012
Below answer is out of date. The venerable FormsAuthentication.Authenticate is now marked as obsolete in ASP.NET 4 MVC 4.
MVC 4 ships with the new brand spanking WebSecurity authentication system which solves a lot of problems of the old system. Please look in to it unless your project is still using MVC 3 or below.
Short Answer is "It works very carefully."
Long answer...
User account details are (by default) stored in a SQL CE database (which is in the ASPNETDB.MDF file)
ASP.NET has a built-in Membership and Role Provider system to assist with authentication. This is an abstraction that ASP.NET uses to enable built-in support for accounts. By default, when you create an application, your web.config file is configured so your application uses a built-in implementation of this Membership Provider to allow your application to do the magic of reading and writing to the database, hashing or encrypting passwords, validating users .etc.
The code sample you got, is a part of Forms Authentication
FormsAuthentication.SetAuthCookie(RegisterUser.UserName, false /* createPersistentCookie */);
It is the component that manages Authentication by default. When you perform the above call, ASP.NET Forms authentication system encrypts the username and a session data and stores it in a cookie on your user's browser. (This cookie is removed when you call FormsAutentication.SignOut() )
This cookie is transmitted to your server for every request. So, for each request, FormsAuthentication checks and validates this (decrypts it, check who the user is, validates the session is not expired, and set some properties in the application so your code can know which use is making the request).
If the /* createPersistentCookie */ parameter is set, the cookie is set as persistent, which means the cookie doesn't get deleted when you close and re-open the browser while logged in. This is same as you logging into, say Facebook, and tick the 'Remember Me' check box, and the default implementation of the project created by Visual Studio does exactly this on your log in page.
Hopefully now you have a better understanding about what's happening in the login process. Because of the way these are implemented in ASP.NET, you can easily configure, extend or replace the functionality with your own implementation if you like.
To better understand how things work, follow this article on how to implement a custom Membership Provider http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
I should tell you that if you're new to ASP.NET, reading on how Membership and Authentication works may be overwhelming. (I personally spent the last couple of days trying to understand and write a custom Membership provider to match my requirements. It was a bit frustrating so I took a break to answer you and refresh my mind with the basics.)
If you're happy with how the existing system works, just use it. It doesn't hurt to implement a custom provider to understand how it works. But the built-in system has went through a lot of testing for the last decade and proven to be working. So why not use it ? I've seen multiple custom implementations on different sites that try to replace the existing Membership system, just because they don't fully understand it. Most of these implementations end up re-writing what is already available, and falls short when it comes to extensibility and security. Just like a wise man once said "Don't fix it, if it ain't broken".
Related
SITUATION
I have a database where I have usernames and their linked permissions and code that works with it. Think of it as blackbox that gives me user's permissions as an Enumerable of enum values when I supply username. I need to use it.
I also have an ASP.NET Core 3.1 MVC web application that needs to use Windows authentication and Custom Authorization based on those permissions.
I want to store those permissions for a minute (or ten) because the network is unreliable and querying for user's permissions every time takes a long time and they don't change that frequently. I can't do anything about the speed, I have to work with it.
I have an AuthorizeAttribute implementations where I specify a list of permissions (enum values) that user needs to have to get to the action in a controller.
To be more specific I have an older .net framework asp.net MVC application where I go around this problem by having my own custom principal with my list of permissions and saving this principal in a cookie.
I'm slowly learning asp.net core and when I started reading about authorization and authentication in it, it was enough to make my head spin from information overload.
SUMMARY
I have a list of user's permissions that I need to store for some time and don't know what to do make my own custom authorization happen.
I what I currently have is probably not going to work for me in ASP.NET core MVC application and can't find viable option before getting overloaded by the myriad of options available.
What I need is a push in right direction written in simple language (for an idiot) in a direction to look into to make my requirements work.
CURRENT (NOT IDEAL) SOLUTION IN ASP.NET FRAMEWORK MVC
Example of what currently somehow works in .net framework asp.net mvc, but is probably far from ideal:
in global.asax override WindowsAuthentication_onAuthenticate, where I check if there is a cookie with the user's data and the user is authenticated.
If the user is authenticated but there is no cookie, create a principal (containing the user's permissions) and serialize and encryt it to FormsAuthenticationTicket to the cookie.
in Application_PostAuthenticateRequest get data from the encrypted cookie and set it up in the HttpContext.Current.User as the principal.
The authorize attribute is then just going to take the array of specified permissions and check in HttpContext.Current.User if the user has them.
Can someone recommend me how to narrow my search for a viable solution (or a viable solution)?
We have two servers that run on the same machine under the same domain.
Both written in ASP.NET and uses the Identity framework.
I need to implement Single Sign-On (and single sign out) between them.
Actual sign-in is done in AJAX (I POST the username and password, the server authenticate the user and sets the session, then sends the redirect data URL to the client).
I found overwhelming amount of information about OWIN, the Identity framework, Claims, etc.
I found tutorials explaining how to create projects using just about any modal dialog and any Wizard there is in Visual Studio, which I tried to understand but really is useless to me, as I already have authentication system up and running.
I even found some demos claiming to implement SSO in all kinds of ways, and some Stackoverflow questions that said to simply put this and that values in the web.config and you're done, which seemed strange to me and I figured out I'm missing some basic understanding of how it works.
Still, I can't understand how SSO works in ASP.NET Identity.
Can someone please explain it to me in a simple manner, or refer me to some kind of such explanation?
Again: I have two authentication systems up and running. What code and/or configuration changes I need to make to get Single Sign-On working?
First, if you want them to share authentication, they need to be working on the same user store. In other words, you should factor out the Identity initialization code (ApplicationUser, ApplicationDbContext, ApplicationUserManager, and ApplicationSignInManager) into a class library that both applications share. Trying to mantain and share two separate databases with user data is going to be an impossible and insurmountable task.
Then, you need only ensure that both applications utilize the same machine key. The auth cookie is encrypted, and since the encryption is based on the machine key, both applications need to use the same key to encrypt/decrypt that cookie.
Since you've already stated that they will both be hosted on the same domain, that's all there is to it.
I am very new to Sitecore.
I am converting a web forms application to a Sitecore application where I make an ADFS call and get the user to login. The application returns a Claims object with the Name and EmailAddress.
However, in case of Sitecore, I read that Sitecore directly implements IIdentity and IPrincipal and hence is not possible to utilize the Claims with Sitecore Identity and User (Principal).
I've tried referring to this article.
And downloaded and installed the ADFS.Authentication package.
I have also made changes to the web.config as mentioned in the article.
As i understand, all I need to do is call the Login method:
AuthenticationManager.Login(userId, false);
However, when I run, I get this error:
AuthenticationHelper has not been set. It must be set in Initialize.
How should I proceed? As I understand, by downloading the ADFS.Authentication package, I do not need to do anything and this should take care of converting the claims too. Is my understanding correct?
Please help me.
Thanks!
I've implemented something similar in the past and to get this working I've setup my own Httpmodule to handle the communication back and forth from the remote systems and I did not implement IPrincipal.
Then when authenticated, I log in the user as a Sitecore virtual user and store any information in an encrypted forms cookie, this keeps things nice and simple and you don't have to worry about anything conflicting with Sitecore.
More info on virtual users here:
http://www.sitecoreinsight.com/lightweight-authentication-using-virtual-users-in-sitecore/
I know this question as been asked countless times, but believe me I've searched Google for hours and got nothing. Whatever is out there, it's for MVC, which I'm not using.
My requirement is simple. I do not want to use the default authentication provided in asp.net. I would store the username/password/role in my custom SQL Server table. I'll provide 2 inputs for username/password and a button to validate. On validation, he is allowed access to the admin areas. This will only be used by admin guys at my subdomain "admin.*.com". They will use this page to add content to the website on daily basis.
How do I implement it. A tutorial link would suffice.
Is it safe for Production? I don't want some newbie hacker getting in to my site and mess it up. If not safe, what else option do I have.
Thanks,
Dev
As per our comments, given your reluctance to implement an ASP.Net Membership provider (and it is worth the time to investigate - you may not feel that it is right now, but it can be handy. I felt the same way at first, but the cost of maintaining your own code and infrastructure soon proves to be false economy) you have at least two other choices:
1) Straightforward Forms Authentication
Put all of your admin pages under a single folder, for example, /Admin, then use Forms Authentication to protect access to this folder. Only users defined in the database or Web.Config will have access to these pages. This is less flexible than ASP.Net membership, but may give you most of what you want. In terms of security, this will be as secure as your website is, is well tested, and is well documented.
2) Use Facebook OAuth
You mentioned that your use has access to Facebook. You could use Facebook to do the authentication for you. Although you wont be able to grab the username and password, you can get a token back, that you can then validate against a known permission set. This is a lot more work than 1) though and will tie you to potential future changes in the Facebook API. However, it also benefits from being well tested, and secure, but you have little to no control over the actual user information.
As an aside, please also consider being nicer to Google!
You can create your own custom membership provider which has the features you are looking for.asp.net membership provider
Its best to use the tried and tested method for security purposes. Remember you can customise any providers including role providers or even create your own unique providers.
Here is an example how to LDAP authentication using ASP.NET 1.1. The logic may still be applicable or can be adapted to later versions of ASP.NET, although I have not tested it.
Using the built-in membership providers, or implementing your own, is no guarantee that a hacker can't get access to your system. Things you'll have to consider:
encrypting data between client and server
don't store passwords in the database, not even encrypted. Hash each password its own salt, if you can.
enforce strong password entropy.
make sure session and authorization cookies are marked HttpOnly and Secure
for admin passwords, have a policy to change them frequently (like once a month)
provide means to notify administrators when someone signs in to their accounts
temporarily lock out ip address who exceeds number of requests per second and failed to authenticate
temporarily lock out users when they enter their password more then x (e.g. 10) number of times in an y number of minutes (e.g. 10).
These are just a handful of things to look for. You'll also have to concern yourself with session highjacking, javascript attacks and so forth.
Its not a trivial matter.
Writing a custom authentication handler is very dangerous. There are many ways to get it wrong and leave your website vulnerable to attack.
I also understand your complaint that Forms Authentication is extremely complicated. I was faced at a similar cross roads and decided to build my own authentication system called FSCAuth. It's BSD licensed. It's designed to be super simple and to allow for just about any database format you can image. All that must be done to set it up is implement a small 4 function interface into your database and populate a few configuration fields.
I have been tasked with developing a single Login and Dashboard page that user can login too, the user will then be shown all the systems (we developed) that they have access based to based on some roles stored in our databases.
If they logged in we would like that "User Session" (not sure of correct terminology) to be carried to which ever system they are redirected too.
To illustrate a very rough overview of what I want to achieve:
alt text http://www.pcbg.co.za/attachment.php?attachmentid=12165&d=1268903524
Is there a way that a user can login in one site, and then carry over that login to the other sites?
Help, Advice, Link will be much appreciated.
Sorry I am not experienced at ASP.net but have a good understanding of Silverlight, C#, WPF.
Thanks in advance.
You can use the concepts of single-sign on. You can manage your session data as out-proc, i.e. in a SQL server or a State server. Here are couple of links which will give you some pointers:
ASP Allaince
MSDN
Edit: Alo look at this question in SO:
One method that I would use is that you implement your own authentication system - almost like the ASP.NET 1.x days. However, the trick is that you establish a cookie for each domain (host part of the URL) with an authentication cookie.
If all of those systems are running on the same server, I am sure you will be able to use all the FormsAuthentication methods and the Membership API. If they are not [edit: hosted on the same server], then ensure that they configured to encrypt the authentication cookies with the same keys. Implementation of this bit will be by what mileage you need to do...
One thing to notice is that you may also establish only one cookie is sent to the browser but shared by all the applications. Imagine that you have the following URL's:
dashboard.com
myapp1.dashboard.com
myapp2.dashboard.com
myapp3.dashboard.com
Setting a single cookie to the domain "dashboard.com" will send and share the same cookie to all the other domains.
The shared session states as described by the other posters will not work. The way session variables work on the server is that an unique key is generated on the server for your data storage (whatever the medium is: in proc, out of proc, SQL server). That unique key is stored in a cookie where it is sent to your browser as the host part.
I hope that gives you some insight on how to go about tackling the single sign in solution that you are making.
One way would be to use the session state service that ASP.NET provides. Basically once the user logs in, that session could be stored on a separate process (and not be a part of aspnet_wp). All your applications would need to be modified to go to that machine to fetch user authentication status. Search Google/MSDN for Session Management techniques.