I've started an ASP.NET web site in Visual Studio using a Microsoft pre-defined template. This is to help me learn about OpenID within ASP.NET.
Inside the included SQL database within the sample site, there is a table called UsersOpenAuthAccounts that contains a column called ProviderUserName.
Can anyone tell me the purpose of this column? In my tests, this seems to store the username that I would log into an OpenID site with (e.g. my Google username - my email address). However, I also see that the ProviderUserId column holds the IAuthenticationResponse.ClaimedIdentifier value, e.g.
https://www.google.com/accounts/o8/id?id=AIt................g3c
...which would be used to identify the user against the OpenID provider for future requests.
Therefore, is there any point in including the ProviderUserName column? It's not actually used anywhere else within Microsoft's sample site.
ProviderUserName is... a bad idea (IMO).
The OpenID Claimed Identifier is the right string to check for return users. It reduces security to use anything else, including email address. If you're only interested in OpenID logins then you may want to just throw out the ASP.NET provided code and use DotNetOpenAuth's OpenIdRelyingParty directly and deal with the users table yourself. It will be about as simple as your current code, but without the unnecessary columns.
What the ASP.NET team's additional column and façade classes give you is the ability to mix OpenID logins with OAuth logins, which allow you to accept Twitter and Facebook accounts at your site as well. OAuth wasn't designed to be an authentication protocol, so those who use it have to make up their own idea of a username. In order for that to be globally unique, it must be prefixed by the provider who is issuing that username. So you have ProviderName ("twitter" or "google") and a ProviderUsername which is the username (or user id perhaps) of the account from the OAuth service provider.
Related
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
Problem statement:
Hi. I have some secured data which I want to expose through Web API and ASP.NET Identity mechanism. I want to use out of the box classes of ASP.NET Identity. I take a payment manually and change a value in the table. But there are cases where the user will share his username + password with some other guys so that the others can access the same content without paying anything.
Work plan:
So, I have extended the AspNetUsers table with a column named ApplicationToken (varchar). After successful login, I want to generate a token, update the field of the user's row in the table, and add this value as a claim information and send back to the client app. Now, when the user requests for a paid content, my client app will send the token also. So, somewhere in my server side codes, I need to check this ApplicationToken with the Database token value. If both are equal, I allow the request to proceed, otherwise I will send 401 Unauthorized and tell them to login again.
Implementation options:
After studying and searching, I found the below options to implement:
Create Custom Authentication Filter attribute so that I can grab the claims send from the client and do my required validation
Create a base class of the secured API and get the claims there and do my required validation.
Go for different Jwt based implementation where I should have access in both issuing and checking the Json Web Tokens.
If you have any other options, I would be very glad to hear those.
My question is, which approach is better to proceed. I have enough time to implement, so time is not a factor here. Thanks.
The customers (clients) of an ASP.NET webapplication are companies and each company may have many users that have access to the site.
So, for instance CompanyA subscribes to the site to consume the site's services. Immediately a superuser of that company is created. Then, this supersuser has the permission to create more users of CompanyA that have access to the site.
So, in general, each user is identified by a CompanyName and a UserName.
Typical ASP.NET forms authentication provides automatic login and register functionality but only with Username and Password fields.
Does the .NET framework provides a way to include a CompanyName and CompanyPassword fields in the Login and Register controls?
A company and the initial superuser may also be registered in the system by the Site's administrator.
Actually what I would like is to include a CompanyName field in the provided .NET Login control, and not only Username and Password.
Is there a .NET framework way to do this, or do I have to custom-code it? In the latter case, which is the best practice?
Your scenario should NOT require a company name at all. So long as the username is a unique column, you should be able to lookup to which company does the user belong to. All you need is a user_company table which will link usernames to company ids. Once the super user is created, you know the company he belongs to and when he creates a user, you also know which company that user will belong to. On the login page you still only need to ask for username and password only; that's of course, if you don't want to allow users from different companies with the same username, which I think is reasonable and a good trade off for simplicity.
You can use any pre-existing or planned authentication scheme you want with ASP.Net Forms authentication.
See this (overly simplified) example from MSDN where you can even hard code the auth scheme if you so choose - not that you should, but it gives you the overall idea.
ASP.net Membership is provided to you by Microsoft if you want to use it (you don't have to). It has all the scaffolding you need if you use it (including the database you mention) and is used by Forms Authentication by default (not exclusively).
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.
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.