I currently have a website and upon registration to the website i generate each member a unique GUID. Upon the user logging in to the website i check the credentials and store the guid in session if successful, in order to show the user there profile / how many post have been made etc i run my queries to the database passing the users session GUID to fetch data related to them.
Can anyone kindly confirm a better approach for this ?
Have a look at the membership features in ASP.Net: http://msdn.microsoft.com/en-us/library/ms998347.aspx
This is basically how most authentication/authorization systems work. Some things you may want to keep in mind:
Don't reinvent the wheel if you don't need to - as Max pointed out, ASP.NET has a built-in auth provider that is fairly feature-rich and can be extended as well.
I would avoid storing anything in Session unless you have to. It is easy to get lazy with Session, and it is also potentially volatile - if you bounce the service, anything in Session is gone.
If you store a cookie on the client to handle this, ensure it is salted and encrypted.
Related
I've an AspnetCore + Angular setup where the authentication part is handled by IdentityServer4. One of the requirements now is to get a list of all users who are currently logged in. Any ideas/suggestions how to proceed on this?
PS: Just in case it's needed, I'm using implicit flow .
Auth is persisted via a cookie, which lives client-side. The server doesn't know who all is logged in. It only know in the context of a particular request (where the client sends the auth cookie back) whether that particular client is authenticated or not.
If you really need this, you'll need to manually track it yourself somehow, like adding a record to a table for each login. However, this can get gnarly fast. You'll need to also manage sign outs and expirations, to keep your custom data fresh.
A generic answer could be: ASP.NET CORE keeps each user session in a cookie, separately located at each user's browser on each device. Once you need, you have to centralize that system yourself. Howerwer, since the question regards Identityserver, we can look into what is already done in that area by the IdentityServer authors. And they have provided at least two extensibility points.
The first one is to employ Reference Token (instead of the jwt by default), then look through the persisted grants database, fetch all the sessions grouped by userId. Not a standard way for OpenIdConnect, but it exists.
The other approach is to implement your custom session store based on a database (instead of the cookie based by default). That provides you access to all the clients logged in with the given user id. Here is my old (but still valid) example of a hybrid (cookie + IDistributedCache such as REDIS) extension for the DefaultUserSession. Usually after the requirement to list all the user sessions, appears the other one: to create a kill the session button next to each row. Here you have to be careful with access token lifetime (make it reasonably short), as a jwt once issued can not be invalidated before its normal expiration.
There is provision in the default cookie provider in ASP.Net Core to use a DB or distributed cache to store cookie payloads. Check out the Microsoft.AspNetCore.Authentication.Cookies.ITicketStore interface and the CookieAuthenticationOptions.SessionStore property.
We created our own implementation that stores auth cookies in the PersistedGrants table along with IDS4 stuff. It works well, keeps cookies small and facilitates a "sign out on all devices" option also. If you align the expiry of the entry with the cookie authentication properties then the housekeeping is done for you.
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 an asp.net (webforms) application and I would like to track user visits to the site. I have the DB, objects, basic idea down.
My goal is to track a user from the first time he enters the site and up until he creates an account. So I can trace back where this user came from in his initial visit (Organic, paid, referrer, etc.).
I am planning to create a cookie with a GUID for each initial visit, store all actions in the DB, and finally, when the user registers, I can go back and update a username field for all rows matching the GUID.
My problem is that I can't make up my mind on the best method to do this.
Should I use an HTTP module and the session start and end events,
or maybe ajax calls to a WCF backend?
What would be the most efficient and accurate way to do this?
Unless you plan on supporting anonymous sessions (which depending on traffic may or may not be an option), Session won't work.
The simplest thing that could work is simply putting a ticket (like your guid) in a cookie. You can set and retrieve Cookies from your Page and use that to track the user. This does mean you'll only be able to track a user when he accesses from the same machine but until he's authenticated, you don't really have that much of a choice.
My asp.net session objects are storing in SQL server.I am storing an ID in session. If client open another browser and storing different ID in session. I need to notify client is “are you sure you want both ID’s open?” in same based user logged user.
Application runs on logged in user (not anonymous)
How can we check this in asp.net?
Session is not linked to an authenticated user, and there is no way of accessing an other connection's Session without knowing its SessionID.
Usually this kind of problem can be solved using cache instead of session state. With cache you can create your own user-based keys to store data. Depending on whether you are planning to just run your web app on one server or in a web farm environment, you can either use asp.net in-process cache or one of numerous distributed cache solutions (like memcached which I'm using in my web projects with great success).
There are a couple ways to go about this:
Option #1, in your user table, add a value called "session id"
When a user logs in, check to see what their last session id was. Then test to see if it's still a valid session. If it is, ask them what they want to do. Store the latest session id in that table after each log in.
However, I'd go with option #2: Don't do this. If the user wants to open multiple browser windows to access your application then let them. There's probably a pretty good reason for it. Most (as in nearly all) users have no idea what "session state" even means and they really have no desire to know. All they care about is getting their job done.
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.