ASP.NET Membership/Roles/FormsAuth - how can I login as a super-user?

I'm working on a web application that uses the ASP.NET 2.0 Membership and Roles providers with Forms Authentication. There are various roles in the system. I need to have a user role that is essentially a super-user that can "login" as any user account (in effect impersonating the user).

Does anyone know if this is possible using the providers? Any ideas?

One approach I was thinking of was to logout the super-user and sign them in as the desired user with

FormsAuthentication.SetAuthCookie(username, false);

And adding a variable to their Session to flag them as a super-user. I think this would work, but I was just wondering if there's a smarter way to do it without directly using the Session object?

From stackoverflow

• Why don't you have a SuperUser role that can do anything? Then the user can be just part of that role.

  If what you really need to have is an ability for an administrator to impersonate someone else, I don't know what is the additional flag for? If it marks the currently logged in user giving him super powers the same will be achieved by setting up a role. If you, however, need to just impersonate someone else (e.g. this is help desk and you need to see exactly the same as the end user sees) - I would just check the credentials normally, then check if a superuser is logging in and who they want to impersonate and based on that just authenticate the logging in user as the one that he's willing to impersonate.

  I hope what I wrote makes sense...

  Andrew Corkery : Hi Pawel. Thanks for your feedback. I mightn't have explained it properly - the site uses Personalisation so that a view is different for each user and this is leveraged by using HttpContext.Current.User.I need this to be the logged-in user, but also know that it is a super-user.

• Asp.net approach doesn't support the concept, so you are right on trying to find an alternate way. Something that you can do is add the IsSuperUser info to the authentication ticket UserData property.

  Andrew Corkery : Thanks Freddy, I think I will go with this suggestion. Storing this information in the authentication ticket seems the most correct place for it.