I am a little confused as to how the identity framework works. For example in VS 2013 we can create an MVC application that the authentication is individual user accounts. Once we create it we can register with a username and password. But what if we wanted to have also a DOB in the registration or some other fields such as email or phone etc? Can we do this with the identity framework? What about the way the data base is structured, can we have a custom structure? Or if I want this should I be using forms authentication? Also what is the difference between the Identity framework and Forms authentication in terms of authentication?
Although your post has already been marked as answered, I’d like to add a little more info for future readers.
The first thing we need to understand with VS and Microsoft is that they’ve always tried to provide us with Templates to help us get started. There are many Pros and Cons to using Templates but the idea is that it gets you started quickly without having to manually include stuff yourself.
The idea of Templates is great but to the untrained eye, it provides Microsoft an opportunity to include stuff that THEY think you’ll need or better yet, what your application will need.
This opportunity includes promoting products such as Identity, Knockout.js etc...
In short, Microsoft is not wrong in doing that since the majority of the people do not second guess what is included in their project and because they…well…trust Microsoft.
A great analogy is when you purchase a new computer from a major retailer. When you arrive home and start your computer, you quickly notice that you have a bunch of pre-installed software running in the background (that you never asked for).
To the untrained eye, they will never realize that these are running in the background and their computer will work regardless. But for someone that is aware, he will most likely uninstall all of them and have a cleaner plate.
So Templates are similar to this...
As for the rest of your questioning, I’m sure by now you’ve found the answers.
Even though Microsoft sells ASP Identity as a single solution, Forms Authentication and Identity (Membership) are two distinct frameworks that work together, but serve different purposes:
Forms Authentication manages authentication session/cookies.
Membership/Identity is the store for user information (credentials, user demographics, etc.)
Look here for some additional information and links.
Related
I find a few topics on this, but they point to too-generic documentation or, for the link that seemed most pertinent so far, don't work.
(I'll refer to all the built-in functionality for membership/roles in .NET as "Membership" here on out.)
Using .NET 4.0 and Visual Web Developer 2010 Express and SQL Server 2005.
I'm creating a website where, in order to sign up, you need to be a paying member. I've already created the database that holds all membership info, and I've already created the form where they sign up, as well as the pages where they themselves or site admins can manage their account info. I've also even created a class for authenticating them and checking for permission on pages based on level of access (roles).
I'm hoping for a clear, concise explanation of either of these options:
• Point "Membership" at the place where username/password are stored, disallowing it from auto-creating its own db. (I'll then go back through my site and replace my own custom authentication in the few places I have it with official .NET "Membership".)
• Or still run my own custom authentication, but in that process, say to "Membership", "Hey! User known as "username" and of role "member" is now authenticated. Note that in your own special place, assign them that role, and know what to do with it when I ask you hereafter." Could this be "Forms Authentication API"?
There's more to the account than just username/password/role. I know I can add more fields to accounts created using .NET but I also really don't want to use some randomly created, self-contained, disjointed database just for the sake of handling logins.
I have not yet learned the basics of "Membership", though I'm getting darn close in my process of learning .NET; and I can't spend the time right now making progress on that for personal reasons, but I have to proceed with making this site. I would like to be able to use many of the benefits that come along with .NET security, like being able to exclude users from folders using web.config, etc.
Mostly I'm just seeking assurance it will be possible for me to backpedal after I get some other aspects of the project shored up, but before I make it live, and without having to rewrite half of the membership forms and splitting that data into several databases and figuring out how to use "Membership" for either pieces of it or all of it when a member signs up.
Possible?
If I understand you correctly, what you are working on is similar to something I am working on here.
We have a custom authentication scripts in ColdFusion and I am creating a second .NET System with Membership login.
The way I went about it was to move all the user/role/profile information into Membership's tables and created an additional tblUserProperties table which holds all other information that the Membership standard tables cannot hold.
I have recoded the ColdFusion queries to point to the new Membership tables.
This way, if a user change password from either system, the logins will work from the other system as well.
I think keeping two systems/tables that do the same thing (authentication) is risky because of the password change reasons. There could be more, but why can't you just simply change your custom code to point to where Membership is pointing? That way you can use Membership provider to its full potential.
Hi ive asked this over on the offical asp.net forums aswell though it would hurt to ask here to.
First some background information (feel free to skip it)
i've only recently started learning asp.net web pages
To start i picked up a few books, that went through web security register/login etc. Using the WebSecurity class.
A while back I made my own website to sell/distribute my own software. This was done using php & mysql.
However ive been wanting to update this as well as build a few more product oriented websites. And just use the main site as a store.
I could do this in php but I would need to brush up on it first. Which given my situation isn’t the best use of my time. As lots of jobs ask for experience using asp.net as well as several years programming experience part of the reason I decided to try and develop my own software. But it it doesn’t work out ill need a job which is why I started learning asp.net.
Now the problem
For my existing site I chose to generate a string of random letters and numbers to use as ids for products, customers etc. I do the same in my software as well instead of using the auto increment in the data field so id 1,2,3 etc.
instead I have strings like a3hgt4ssf, 3243dfsa, sdas342d.
Initially things started okay using following the book using WebSecurity and along with the role provider to deal with logins, creating users, restricting access etc.
Then I found out I had to use the auto incrementing ids. So I started creating my own web security and role provider based upon theirs same functions etc.
But now im stuck initially I stored some data in cookies loggedIn, customerid, username no password then I just checked for the is login cookie. This was how the books did it when I first started learning web development but I moved to software and haven’t followed it to much over the years (lack of time).
Now im not sure if I should be using cookies (same as before) or not, or should I use sessions which expire when the browser closes (as far as I know)
My main concern being security i'm using paypal to process payments. So I think that makes it less of an issue but still.
Im also aware of the size of the .net framework, so I don’t want to reinvent the wheel if features are already available to the accomplish what I need.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...
I'm not sure I'm asking the right question here, but I'm looking to provide web based functionality from one ASP.NET application to another remote 'portal-like' application. Is it possible to simply give the portal a DLL? As an example, let's say the SaaS web app has a patient-entry form that I want to be able to use from the portal application. I would like the portal app to be able to set preferences (permissions, color, style, etc), make a function call, and have that capability presented within a certain div or something. Is there any .NET technologies that provide this kind of integration?
EDIT:
Here is a link to a quick diagram I made trying to describe the scenario: http://img.ly/ESG. I know there are other ways of doing this (eg JSON-P calls), but I need to give the portal developers something they can control on their end. Also, if anything changes they'll know I will send them a new version of the DLL which will indicate to them the new functionality.
I'll give you a shopping list of things to check out:
DotNetNuke:
http://www.dotnetnuke.com/
Workflow Foundation -
http://msdn.microsoft.com/en-us/netframework/aa663328.aspx
Microsoft SAAS platform -
http://www.microsoft.com/serviceproviders/saas/default.mspx
Depending on exactly what you're looking for, you might also research "multitenancy".
To answer your original question, yes, you can do it with DLL's, but there are easier ways to do it.
I am currently converting a very old, but working classic ASP site to ASP.Net.
It has a completely custom written user management system. Whilst it works fine, it really needs a refresh as I want it to be more flexible for some future projects in the works.
When I asked someone about this, they said "You need to use the Microsoft Provider" and gave a lecture on how Microsoft release all these things for free and how good they are and should be re used as much as possible.
I have done quite a bit of research on it (mainly looking at the videos on http://asp.net/learn ) and am very impressed by some of the features as there appears to be drag and drop components for items that would take me ages to write.
However, the current membership database is complicated to explain, it is a completely custom written database that has many internal relations... It is not really "compatible" with the default Microsoft Provider.
I have taken a look at How Do I: Create a Custom Membership Provider?, but I feel a little out of my comfort zone and worried it will either be slow, introduce a security hole or simply won't work.
At the end of the day, the Microsoft Membership Provider should work for me - the only customisations I really need is the login to use the username/password field in my database and the create user script which has a lot of custom code to several third party systems (needing to provision services etc.).
I was just wondering, what would you do if faced with a similar situation?
Use the Microsoft Membership Provider and somehow get it to work for you (although I would like suggestions)
Use the Microsoft Membership Provider but use custom provider that is customised around your code.
Use your own completely customised solution?
That video does complicate things :) If you're going to implement a custom provider then reflector over the existing one is a good place to start :)
As a quick and dirty option you could, of course, hack the stored procedures that the SQL Membership provider uses but the custom code to provision services is probably stretching that.
If you think about it the remote provisioning of services doesn't really belong in a membership provider, it's not really a membership function - all membership does is provide usernames and passwords and authentication around them. My own feeling is that you should move the provisioning of services out of there, and perform it on the ASP.NET site after a user has been created - even if that's just calling a stored procedure once the membership provider has done its thing. If you do this you may find that the SQL membership provider will do everything you need it to (probably with the Roles & profile providers too), and thus you have way less code to write!
I've been in similar situations in the past. In both cases we created custom implementations of the providers (MembershipProvider, RoleProvider, ProfileProvider) around the existing mechanism.
In both cases we only used the provider implementations for read-only access, e.g. to give us the easy validation gubbins in web.config and suchlike. The user administration code was left well alone as it worked just fine.
If the existing provider works (has the right fields for your data), use that to start. You can VERY easily replace that with a customer provider later (just a single config value change).
Beware there isn't an "out of the box" ASP.NET management interface for that, you'll need to roll your own or use a third party one.
Use my specialized MembershipProvider to work against my own database tables.