How is the claim inserted into HttpContext.Current.User? - asp.net

When I am debugging my ASP.NET MVC application, I find that there is a lot of information in HttpContext.Current.User. As the pictures below show.(I cannot paste pictures directly in my question, I can only offer the link. Maybe someone can help edit my question?)
The fist picture
The second picture
When and how the claims are inserted into the User object? I can understand that vcn\v0cn430 is my domain name, IIS can get this and insert it into the User object in some step of the pipeline events.
But what is the admin? Is it a windows AD group? I don't think my domain has such a group. Why? Thanks very much.

If you are using Windows Authentication, this is the currently logged on user.
The values are read from your Active Directory.
Also, you can use:
User.Identity.Name;
Windows authentication in MVC
Your application itself can issue claims, using application level names such as 'Admin' as security tokens.
https://msdn.microsoft.com/en-us/library/ff359101.aspx

Related

ASP.NET Identity - Maintaining information about anonymous users

I'm just looking into ASP.NET Identity, which seems that it is the most preferable solution for user authentication in ASP.NET apps these days (replacing all the ASP.NET Membership stuff from the past).
I am looking for a solution that would allow to maintain information about anonymous users. Even if the user is not authenticated, we can collect and store most of the profile data that we could store if the user was authenticated.
Even if the user is anonymous, it makes sense to store data like:
shopping cart
comments he's written on the site (so that he can edit them as their creator)
various site preferences (his preferred language, and many other settings)
Then when the user registers, we can offer to copy some of this data into his new user profile (or copy it automatically) depending on what data it is.
Is it possible to achieve this scenario with ASP.NET Identity? It seems that when a user is anonymous in ASP.NET Identity, he cannot have any user profile data.
In order to use the same tables to store all this information as for authenticated users, we might need to create a new user in the system for every new visitor that comes to the site and does some action that requires storing of some user data.
After that, we'd need to pass some cookie identifier to the user, so that we can always connect the data to the user, which can be seen as some form of authentication (although invisible to the actual user). That way, the guest user could actually represent an authenticated user of the system (maybe he'd just have a special role?), even though to his knowledge he's anonymous.
What do you think about this approach? Are there any ways where ASP.NET Identity can help with this?
I found these two related Stack Overflow questions, but I haven't found my answer in them:
Does ASP.NET Identity 2 support anonymous users?
ASP.NET Identity - Anonymous profiles
Edit:
I discovered that there's a mechanism called Anonymous Identification in ASP.NET that seems to solve part of the issue.
https://msdn.microsoft.com/en-us/library/91ka2e6a(v=vs.85).aspx
Maybe it can be somehow integrated with ASP.NET Identity?
Edit2: As noted in the comments, the documentation for Anonymous Identification seems to be outdated and it's quite probable that Microsoft will not be focusing on this much in the future. Solutions that work with ASP.NET Identity or other OWIN-based solutions are preferred.
Asp.Net Identity has no such thing, and it will not be secure identify the anonymous user even through hip IP or a Cookie in his browser, you can ask the user to register with very minimum info or through FB or Twitter to make the registration process as short as possible, and later he can complete his profile, this way you will make sure the data is linked to an actual profile.
ASP.NET profile properties allow your application to track and permanently store user-specific information. For example, users can specify a postal code or a favorite color scheme, and your application can store that information and retrieve it from anywhere in the application. ASP.NET automatically matches the current user — whether the user is anonymous or logged on — with the personal information that is stored for their user account.
Configuring Profile Properties
You will begin by configuring your application to enable profile properties. You will then define the first property that you want to track for each user. This property is named PostalCode and will be tracked for both anonymous and logged-on users.
Source: https://msdn.microsoft.com/en-us/library/taab950e.aspx

Converting from Forms Authentication to Windows Authentication

We're currently using forms authentication for our intranet site and would like to allow users to authenticate via windows authentication instead. How will this affect current user accounts, profiles and roles. I have seen on the web that I can mix the two authentication types and put roles and profiles in a separate DB, but how do I link up existing role and profile assignments with windows authentication user logins?
I'm not sure if you can do it exactly what you are asking however you could code your way out of this, you could write functionality that requires people who are windows authenticated to enter a credential you already have on file which is unique (say an email address) you could then convert the user account programatically if they responded by clicking a link.
You could create the new account and import the information from the old non windows authenticated account and then delete the old account. All db records that relyon UserId however would need to be changed in this approach as part of migration.
Depends on how integrated you want to be but if it's single sign on that't driving this.
get the user's sid look for it in profiles roles etc (could add sid column to them but a simple sid - userid table would be better.
if they are in there you are good to go.
if they aren't use the forms athentication to identify them and add a mapping from their sid touserid. So they'll get asked once more and thats it.
You'll probably need a similar mechanism anyway, in the event of the sid changing, which can happen after various windows issues. or for say anonymous access for non windows users.
if you don't like sid as an id then some other e.g domain\user name might do it.
windows groups/roles to application roles for full integration is another step, as would
rationalising profile info like full name etc..
it's nice quick start any way without having to trawl through everything that uses user id now and change it.
Finally coming back around to answer the question. We actually kind of scrapped what we had in our Forms Authentication. The Roles work pretty differently with Windows authentication, as does the profile. We used a custom profile provider rather than the built in profile provider. If anyone is interested in what we've done, I put together a series of four blog posts that detail what we did in our environment and some of the glitches we ran into: Part 1, Part 2, Part 3 and Part 4.

Impersonate a membership user in ASP.NET

In a generic asp.net website with Membership, Roles and hashed passwords enabled, I would like to provide the administrators with impersonation so that they may browse the website as that user would. The website should function as if that user is logged on and then be able to revert to their own login.
What is the best approach to achieve this?
An example use-case: A website with two types of users: 'Buyer' and 'Admin'.
The website provides a 'Purchase' button to buy something specifically provided to the user by the admins. i.e only that buyer can use the purchase button and make a payment.
User has trouble so a support admin can 'impersonate' the user's login and purchase on their behalf or 'see' the trouble they are facing.
Without impersonation, the only way is to allow this in code and that negates the purpose of 'seeing the user's issue'. Not even if I was not using hashed passwords and had used FormsAuthentication.SignOut() and manually logged in the admin as the user.
I hope i am making sense above.
Take a look at this sample on codeproject.com. I think it does what you're looking for.
I don't have the code we used to do this in front of me (assignment from a few years ago), but there are bits in the Membership API to sign someone in using code. I will not have access to the code until this weekend, unfortunately, or I could quickly share the bits and be done with this.
I do remember you had to get the user first, as a MembershipUser, using the Membership class. I am not sure, from this point, whether you had to validate against provider or what.We did use a custom provider, but I forget whether it was related to this solution.
Regardless, examine the security bits, focusing on membership and membershipUser.

How to track and load a specific user's information?

I'm making a small portal in ASP.net (with C#.net4) where users can login and add, edit their personal information (PI). But I don't get how to load information (stored in a SQL server DB) in the page when a specific user is logged in.
For example: If Sam is logged in, he can view his PI. When Vicky is logged in, she can view her PI.
who can help me with this?
thanks in advance.
You need to retain the ID of the logged in user in a session variable and then use it to filter the query with which you fetch each user's info.
So if a user's ID is 278 then your query would run as:
SELECT first_name, last_name, * FROM user_table WHERE user_id = 278
From a session variable stored like:
Session["UserId"] = currentUserId;
The ASP.NET membership provider has already taken care of this for you. Have you considered using it? You can manage all of your authentication, permissions, roles, and access/edit profile information -- which you define. You access the data via the membership objects, and you won't need to write a single line of SQL to do it. It will save you loads of work instead of trying to reinvent the wheel.
Use the regular membership as described in the other answers. Then leverage the Profile system so that each user can view/edit their info when logged in (per the question). CAVEAT: ASP.NET profile system only works out of the box with the Website project template. If you want to use the Web Application project template, then follow the steps here:
ASP.NET: Web Site versus Web Application Project
When you have the profiles up and running, the profile data can be stored in session objects while the user is logged in.

secure way to authenticate administrator in ASP.NET site using OpenID with DotNetOpenID

Encouraged by SO, I'm trying to write an ASP.NET site that uses OpenID for user authentication. It's a regular WinForms site (not MVC.NET), using the DotNetOpenId library for authentication.
Is it safe for me to permit/deny administrative functions on the site by simply comparing the current session's "ClaimedID" (as returned in the OpenIdLogin_LoggedIn event, as member DotNetOpenId.RelyingParty,OpenIdEventArgs.Response.ClaimedIdentifier) to a known administrator's OpenID (i.e. mine)?
If so, is it safe for this ID to be visible (e.g. in open source code), or should it be "hidden" in a configuration file or a database row? (I know it's better design to make it configurable, my question is just about safety.)
My solution is to follow the same idea of the Roles table. After you've authenticated the user, look up that user's roles. If the user has role "Administrator" in the UserRoles table, then they can do whatever the Administrator can do.
I don't broadcast open ID's in my app. They're stored in the table. On every action result, I'm hitting the Users table, since I have also modified mine to store various user state information. With the exception of the home page, there is going to be some user information that I need from that table. I'm using LINQ, so I include the .LoadWith() to load the User with his list of roles when it serializes.
Jarrett makes some good comments about using database tables.
Just to answer another one of your questions, no, it's not a confidentiality thing to put your OpenID in your code generally. If setting up roles seems overkill for your site, a simple equality check against your ClaimedIdentifier is just perfect.

Resources