I have implemented a custom principal approach as outlined here under Step 5: Using a Custom Principal
I then retrieve the user credentials from the database for use with the custom principal, but this results in a database call for every request, so naturally the answer would be to save my user object somewhere, either Session or Cache.
However, it would appear that HttpContext.Current.Session cannot be accessed from within
Application_OnPostAuthenticateRequest, so Cache would seem to be the way to go
The problem is these two answers here and here offer contradictory advice. The first one advises
No, don't use HttpCurrent.Current.Cache to store user specific information as the cache is common for all users and you will get conflicts. Use HttpContext.Current.Session instead as this will be specific to the user.
and the second one advises
Use the Cache instead of session
So which is the preferred method?
If Session is the way to go how do I put my user object into the Session object from the Application_OnPostAuthenticateRequest method.
If Cache is the way forward what problems will I face? For instance, is there a time limit on items held in the Cache? (I know to get around potential conflicts by using unique key from User object)
Not sure if your still looking for a answer but the best place to store the authentication information is in the Ticket.UserData property when writing the ticket.
I am assuming if you are using a custom provider that you are overriding the SetAuthCookie method.
If that is the case then that method will let you pass in the extra information for storing. It's common to store things like friendly username, roles, or other authentication details.
See this link for Setting UserData in Authentication Cookie
Related
I have three levels of users in my website, Managers,employees and normal users. Each of them in different table in my database.
I created a log in form using login tool. Then I created connection and sessions.They work fine.
now my question is what is the best way to check the session in all pages (if it is manger, employee or user). it would be more useful if there is example :)
Thank you for your time.
Pretty traditional and simple, you could use this tried and true method.
Essentially you would use the UserData property of the authentication ticket to store the current users' roles. You can then obtain the data at any time from the current thread's principal.
I am planing to implement a mult- tenant MVC application, where each tenant gets a "sub site" URL, so that rooting would look like:
www.mysite.com/{TenantId}/{Controller}/{Action}
When a user logs into the application, the login shall always be associated with a single tenant (there is no need for single sign on). However, it should be possible that he registers with two or more tenants in the same application. In such case, I need him to be able to simultaneously use both "sub sites".
As I understand it, the FormsAuthentication is using one cookie with a name specified in the web.config, visible in the code through FormsAuthentication.FormsCookieName.
I was thinking about imlementing an approach similar to this one: implement custom cookie creation and checking (using FormsAuthentication.Encrypt\Decrypt for creating the tickets and then manually creating cookies with different names for different tenants). In this way the user could have several cookies, one for each tenant "subsite".
I am wondering, if this approach seems sensible/secure? I was dotPeeking the FormsAuthentication stuff and there is quite some additional stuff under the hood - with a reason I suppose. Also reading articles like this (where the cookie expiration in the secure connection scenario was not handeled properly) makes one wonder, if custom security implementation is really the best way to go...
Alternative to several cookies might also be setting the cookie Path property. If I understand it correctly, the cookie shall be sent only with requests starting with {TenantId} if I set its path when creating it? Will FormsAuthentication know how to handle such cookies? When new ticket will be reissued, will the Path be respected?
And of course, all other suggestions are appreciated as well.
I've got an application that's using the MVC4 Simple Membership provider. I've added some code to the Login method that sets up some session information I need to deal with some security things.
If I close the browser and come back to it, MVC still shows me logged in in the top left corner and the User.Username properties are still filled out, but the extra stuff I put in there, obviously, isn't.
When or where does this "authentication" take place? I tried checking the request and user objects in the Application_Start in Global.asax, but they're still null when that runs.
Is there somewhere else in that authentication pipeline that I can override or call my method to extract the things I need that would be more appropriate?
Thanks!
"Remember me" functionality has nothing to do with Simple Membership, or any membership. And no actual "login" occurs when using it. It's a persistent cookie that is placed on the users system, and that cookie is read when a page is loaded. If it contains the correctly encrypted data, then the user is considered authenticated without having to go through Membership validation again.
What you need to do depends on how you are doing it. If you're storing data in the session, this is bad regardless, because the session can be reset at any time, and session is not connected to authentication. What you need to do, is check to see if the data you need is in the session, and if not, rebuild it. This way it works when you come back later, or if your session is reset.
Session probably shouldn't be used anyways, because it doesn't scale well. A better choice would be to hook into the OnAuthorization method of the Controller class and do what you need there, that way it's done on every page request regardless of what the session may or may not be.
Another option is to create a custom AuthorizationFilter.
I have an ASP.NET application where most of the pages are accessible to all authenticated users via a single sign on module that sets the username into the Session array variable. Now I have one folder A containing one page B.aspx and a list of usernames who are allowed to access this page B.aspx.
My question: how do I elegantly authorize only these users for this one page, or better, for this one folder. Can it be done with the location tag in a Web.config file inside folder A ? If so, how do I connect that config with custom code to check whether the username stored in the session variable is one of the authorized for that folder or page ? Can I use a custom membershipprovider ?
Thanks in advance !
First, you scrap the kludged security methodology, as user name in a session cookie is not a good way to handle this. Okay, maybe a bit too overboard, as low security may be fine for you. If so, you can write a custom handler for the page that examines user name and compares to an updateable list.
NEW: With Session object, you are a bit more security, as the session token is sent over and the name is kept in session, but the Membership bits (below) handle translation of a particular session to a user without rewriting with your custom "this user is using this session" methodology. Yeah, ultimately you can argue Microsoft does something very similar to your software, but you leave the maintenance to them.
Going back to my original direction, there is the concept of roles and membership built into ASP.NET. If you use these bits, you can security trim the page (or even better folder so you can additional pages) to certain users (not as good) or roles (better) by setting up a new web.config with the security constraints.
The cool thing about the built in stuff is you can declaratively set up security and have the pipeline determine whether a user is valid or not without any heavy lifting on your part.
There is plenty of information on Membership and Roles on the various ASP.NET oriented sites.
that can be achieved specifying the user's name that can access the directory separate by commas.
As your username is not defined in web.config rather defined in some session variable you have to create a Form Authentication Ticket for this e.g.
FormsAuthenticationSupport formsAuthenticationSupport = new FormsAuthenticationSupport();
formsAuthenticationSupport.SignIn(UsernameInSession, RoleName, true);
Now you can set authentication rules and location tag in web.config for UsernameInSession.
Is there any relationship between anonymous session ( where random identifier is generated for anonymous user, which enables the use of temporary profiles for unknown users) and a Session state?
If anonymous user is authenticated we need to clear anonymous identifier so that MigrateAnonymous event won't fire again. But why isn’t Asp.Net able to detect that now user is authenticated (since it now has authentication cookie ) and thus doesn’t send anonymous cookie back to browser?
thanx
No. Anonymous identification uses its own cookie. It's unrelated to session state.
For example an anonymous user might have done some customizations to the application. You might want to store the customization info for him/her as soon as he registers on the Web site. If it destroys the cookie at the time of authentication, you'd lose access to the actions he/she had done.
UPDATE (in response to the comment):
While from a purely technical perspective, it's perfectly possible to remove the cookie automatically, I think they had done this to make this step explicit. For example, if for any reason, you want to defer the migration to the next request, you can do that. The other point I can think is that AnonymousIdentificationModule is a completely different entity from ProfileModule. None of them require the other one to do the job. You could have several different custom per user customization modules that would work with anonymous identification. ProfileModule is just one of them (and note that MigrateAnonymous is controlled by ProfileModule and not AnonymousIdentificationModule). So, design-wise, ProfileModule shouldn't touch the anonymous identification cookie. AnonymousIdentificationModule could possibly intercept the request at some time and delete the cookie itself if it wanted to but that would reduce flexibility and you would have lost data if you haven't migrated it.