I have created a webapi 2 service that I need to secure. I am trying to use the Individual Accounts in VS2013 but I after much research I cannot figure out how to:
a. Customize the User model with my own properties (no such class exists in template)
b. Get access to User and Role contexts
I tried using the nuget's EFMembershipCodeFirst package but I noticed its deprecated, this package provided access to the required classes (User/Role).
There are plenty of examples for Mvc but I'm using Angularjs as the front end.
Does anyone know how I can customize the User model that vs2013 Individual Accounts template creates? Maybe I'm missing something obvious? I'm a bit of newbie when it comes to securing webAPIs. Thanks
Edit: UserManage.Create() only takes a password and a username, I need override it to also accept myUniqueId. Any thoughts?
Updated title for clarity + added image.
The classes you should concentrate on are the IdentityUser, UserManager and RoleManager classes.
This example shows you how you can use them.
Because your using AngularJS an option would be to create an ASP.NET Web API backend.
The official documentation is a good starting point to become familiar with ASP.NET Identity.
As per #Horizon_Net's suggestion, I created a custom class that derived from IdentityUser, but used the following as guidance:
Here
Related
Bit of a noob question I'm afraid. I have an ASP.NET Core Web Application, which uses Individual User Account for authentication so it's brought in the Identity bits and created me migrations and an "ApplicationDbContext" for all of the user/roles stuff. I moved the Data related classes, migrations etc into a separate class project to separate it from the MVC project, but other than that it's out-of-the-box. All good. My DB has been created by migrations and I can register and login.
Now, I'm coming to build my app, and I'm not sure where is best to add my entities. The question is should I
1) Add my entities to the "ApplicationDbContext" which was created for me by Visual Studio?
2) Create a second DbContext instance in my Data project?
3) Something else?
I understand that if my app was to use separate databases for authentication and domain data then it would be a no brainer and option 2 would be the answer. But this app is very simple with one database, so I'm wondering if I may be able to get away with option 1.
The ApplicationDbContext that was created for me inherits from IdentityDbContext. I don't know if that has other implications if I were to go with option 1 and add my entities to ApplicationDbContext.
I did start down the road of option 2, but quickly found that things like Add-Migration wouldn't work when the project had 2 contexts. I found that the Add-Migration command now has a -context switch which can be used to tell the command which context to use, but I'm a bit concerned that I will run into other issues. Particularly I am going to be using VS Team Services to build and deploy the app to Azure using continuous deployment, and I don't know if those build and release features will cope with the multiple DB contexts.
Any advice from somebody in the know? This has got to be a pretty standard requirement, right?
Hence your app is very simple one,you can use ApplicationDbContext for your domain models as well.That means, I would like to recommend you to use single context class for your app.If you do so,you can easily manage your business requirements (i.e. any relations between your classes) with the users and Roles on the IdentityDbContext context.
I have a concern where I am writing a custom membership provider, but I'm not sure where to put it. I don't really have any code to show you, but basically the provider needs access to System.Web.Security in order to inherit the class, but it also needs data access (i.e. a connection string + LINQ to SQL) to do simple tasks such as ValidateUser.
How can I write a membership provider that adheres to the principles of DDD that I've read about in Pro ASP.NET MVC2 Framework by Apress? My one thought was to write another class in my domain project which does all the "work" related to database stuff. In essence I would have double the number of methods. Also, can this work with dependency injection (IoC)?
Hope this isn't too general ...
Look forward to the hive-mind's responses!
Edit: I just noticed in a default MVC2 project there is an AccountController which has a wrapper around an IMembershipService. Is this where my answer lies? The AccountController seems to have no database access component to it.
Asp.net user management features are super invasive.
They even spam database with profile tables and what not.
When I had to implement users management of my application, I successfully avoided all that mess and still was able to use asp.net in-built roles, user identities etc. Moving away from all that though cause my domain is getting smart enough to decide what can be seen and done so it makes no sense to duplicate that in UI client.
So... yeah. Still have zero problems with this approach. Haven't changed anything for ~4 months.
Works like a charm.
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.
To use your own ModelMetadataProvider you normally set it in the global.asax.
I'm using MVC Turbine and I need to inject a dependency into my ModelMetadataProvider as well.
Something like this:
ModelMetadataProviders.Current = new MyModelMetadataProvider(ISomeDependency);
How is this best accomplished with MVC Turbine?
The best place to put these pieces is to override the Startup method within your web application (the type that inherits from TurbineApplication). We're currently working on making these MVC2 features easier in v2.2 by introducing a ModelMetadataBlade that will do all the wiring up for you to the ModelMetadataProvider.Current property.
So all you'll have to do is register MyModelMetadataProvider with the container like so
container.Register<ModelMetadataProvider, MyModelMetadataProvider>()
then MVC Turbine will do the rest for you. To get an idea of what I'm talking about, checkout the way we're wiring up ModelValidatorProviders. The ModelValidatorBlade asks the ServiceLocator for all the registered ModelValidatorProvider and wires them up with the runtime.
If you have any feedback or ideas, could you post them to the Google Group? Trying to keep these things organized :)
Thanks!
We've used the Validation Block of MS Enterprise Library for some time with great success in conjunction with custom DALs but we've recently started using the Entity Framework and can't get the Validation Block to work with it. The objects are dynamically created in EF and putting attributes on top of them will simply get wiped out when the models are re-genned.
Can these two co-exist? If not, does anyone have any recommendations for what validation library/simple rules engine would be a good candidate to use along with EF?
Thank you.
You need a validator which supports a "buddy class" (like this example for Dynamic Data). This seems to be a work in progress for VAB. I can't find an example of anyone actually using it yet, but it might work.
Validation Application Block supports the concept of configuration based validation. This way you can separate your generated domain entities from validation. You can use the Enterprise Library configuration tool for this. Simply right-click on your configuration file and start adding validation configuration.
I advise you to read the VAB Hands on Lab document (ValidationHOL.pdf) which is included in the Hands On Lab download. After reading that document, read this article. It explains how to integrate VAB with Entity Framework.
Good luck.