Develop Reference

MVC 5 - Best way to cache user data upon first visit?

I'm building a helpdesk/asset tracking web application using Windows Authentication, ASP.NET MVC5, and C#, with a SQL back-end.
In the database, I'm thinking of linking support tickets and assets to users by way of their Active Directory SID, since this value will not change over time. Their SID, along with some other pieces of information, would go into a table called "Users".
Since I'm new to MVC, what would be the most efficient way of getting the user's SID into the database upon their first visit to the site? I thought about building something into Global.asax, but that seems like it goes against the MVC paradigm.
Alternatively, does anyone have suggestions for a better approach?

The idea is quite common.
For most sites (for example StackOverflow) you have to register. You take a common login service (StackExchange) and upon first login, a 'profile' is created.
Authentication (and maybe authorization) still happens through the original source (in your case AD), while the information you really need is saved in the database.
In the AccountController.Login action, you call ActiveDirectory yourself.
using (PrincipalContext context = new PrincipalContext(ContextType.Domain))
{
using (UserPrincipal userPrincipal = UserPrincipal.FindByIdentity(context, model.UserName))
{
// read back the user from database
// if non-existent: add it using a stored procedure or something like that
}
}

In asp.net, To access login username and id in entire application. Where can I store Login user name and id in application.?

I am developing an application in asp.net using vs2010.
In application, Admin can create different user accounts using Microsoft member registration wizard.
Users can Login with created credential using Microsoft login control.
Now,I have to access this Logedin user's UserID and UserName in entire application's different forms.
Currently I am accessing this details by writing code in all forms by
MembershipUser newUser = Membership.GetUser();
Guid newUserId = (Guid)newUser.ProviderUserKey;
So, where can i store this login user's UserID and UserName in a common place. So I can access this details from common place?
Please Help me.
Thanks,

Well - that depends fully on where you persist the data for your application.
If you use a database for storage, then logically the data should belong in there, in a user table, with a connectionstring to the database in your application's configuration.
If not using databases, then you properly need some file based storage, for example XML or something you invent yourself and then have a parser which serialize/deserialize the data from files.
In both instances, you'll need to consider security and hashing/salting and make sure the data is kept secure.

I tend to use a static helper class, which stores (and loads) data in HttpContext.Items for the duration of any request. So you would just need to call GetUser once per request. If even that is too much for you, you can use a Session, for example - but don't forget that sessions only live for so long, so be prepared to reload the data if it's lost due to session timeout.
The static class has to be somewhere accessible from the whole application - in a web site project, this means the App_Code folder.

Application_OnPostAuthenticateRequest and Custom Principal Caching

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

ASP.NET single page authorization

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.

Role management with ASP.NET inbuilt controls

I am using the ASP.NET inbuilt login and role management solution (creates table like aspnet_Users etc. and gives access to MembershipUser and the such).
However, at this stage I am a bit stuck with the following:
1) I need to be able to Suspend, Unsuspend and Delete (not necessary remove from table, just disable) users from my app. Is this feature inbuilt?
2) I need to have three different user roles, where one of the roles is always assigned by default. Currently I have built an app with no roles. Is ASP.NET capable of doing this?

ASP.NET Membership has concepts for "Approved" and "Locked out" (after X number of failed log in attempts) for users, you can probably use those features for suspending users. 4guysfromrolla.com had a great article series on Examining ASP.NET's Membership, Roles, and Profile , it's worth a look.

I don't think that's available by default, but should be fairly easy to add in.
Roles are supported in the default implementation. However, you'll have to define and assign the roles yourself.

There is a built-in DeleteUser
method. It calls a stored procedure
named dbo.aspnet_Users_DeleteUser.
You can change that stored procedure
to suspend a user instead of
deleting them.
Similarly, there is a built-in CreateUser method which calls a stored procedure named dbo.aspnet_Membership_CreateUser which you could modify. Or, you could use the Roles.AddUserToRole method to set the default role when the user is created, calling it in your CreateUser method (which would first Membership.CreateUser)