I have two solutions in c#:
One solution is identity server with asp.net core identity integration, which on first run creates identity user tables.
The second solution I have API, and project Data Layer, where I will implement custom tables.
How do I approach this architecture design, to make sure all migrations will know each other and there wont be data issues. In case I have to create additional table for AspNet_Users and link it with other table, I only have option to put it in Identity solution, but what if there are multiple links? How can I achieve proper architecture here?
Related
I had an ASP Net web forms application with database using Database First Approach. I then merged Aspnet Identity Tables into my existing db. Then i used Entity Framework Reverse Enigneer extension to convert to Code First.
I got the Code First POCO classes & mappings for My existing db. However for Aspnet identity i got only one file i.e. IdentityModels.cs. NO Code First Model classes.... IS IT RIGHT ? Should i have got those POCO classes for AspNet identity tables as well ??
I also want to refer to User Id of the AspNetUsers table into my db tables...Since there are no POCO classes... How to refer to them ???
Further, There are now two contexts.. a) ApplicationDbContext derived from IdentityDbContext. b) MydbContext.... How to unify them if possible ???
Things seem scattered.
Not much documentation by Microsoft or otherwise...or the framework has become obsolete ????
Any help is appreciated.
It seems WebForms have been ditched starting VS 2017 & .NET Core.
Its time to move on to Razor Pages or MVC.
A while ago I asked this question about using EF with ASP.Net core, and this is working great. Now that I want to add ASP.Net Identity, I'm wondering if the best approach is to add identity logic to the separate project with regular / non-core EF, or into the main core project with EF core, or something else. I see a lot of pages that discuss EF core, but I would prefer to use the same context everywhere, and I would prefer to use regular EF as I am currently doing. I'm looking for what would be a clean / best practices approach here, I have been using regular EF since to my knowledge EF core 1.0 doesn't support stored procs, and I prefer to continue to use a database first approach anyway. Appreciate any help that gets me out of the quicksand.
NOTE: My 'User' table (called something else) has some existing profile data in it; I intend to use this as my Identity User table.
Have you considered having an explicit Identity service that can issue tokens based on your existing identity database?
IdentityServer4 is an OpenId Connect provider. It supports EF so that you can use your existing user data to perform authentication.
The push now is towards .NET Core and it would be a good step in that direction to have a separate project dedicated to handling identity that uses IdentityServer4 and EF Core.
ASP.Net Identity Framework is designed for Code-first, and will normally try to generate its tables for you. I'm not sure if it is able to work Database-first, but I think you could get it working as follows:
Create a separate, temporary, project/solution with Identity / Individual User Account.
Insert the data structure from this temporary database into your main database, merging AspNetUsers with your User table.
Delete the temporary project/solution and database.
Update the models in your EF6 project. This should bring in the new tables.
Add Identity Framework to your ASP.Net Core project, referencing the database context from your EF6 project.
I haven't tried this, but having worked with Identity Framework quite a bit I can't see a reason why it wouldn't work.
Further reading:
Database first Identity: Using Asp.Net Identity DataBase first approach
Custom table name for Users table: How can I change the table names when using Visual Studio 2013 ASP.NET Identity?
I am trying to update an older website. It already has an existing database with a user and a role table, with existing data in it.
I need to create a new web-api and a new web project and integrate ASP.NET Identity into the already existing database.
I have currently setup my solution to breakup the projects as follows:
Domain
Services
WEB_API
WEB_UI
My aim is to implement the Identity in the services layer so that both my WebAPI and MVC site can utilize the same identity mechanism.
I am fairly overwhelmed at the moment, I have read many tutorials and articles over the last day or two and have ended up with the options of either re-implementing the IUserStore and IRoleStore. And also with mapping the different entities in the OnModelCreatingMethod.
I cant seem to find a tutorial which is aimed at what I want to do. My database is to different to simply remap the names of columns, And I dont want to re-implement the entire Identity Stores as there are only a few conflicting fields. Most tuts I have found are related to using mysql instead of EF. I still want to make use Entity Framework.
Issues I have:
The current Users Table in the database used Int pk , not GUID
The Password Field uses a different Hashing algorithm. So i would need to override how Identity checks and store the password.
I do not have all the required Identity User fields in my database, however I am able to add new fields, I just cant change already existing fields.
I am making use of Database First as the DB already exists.
So basically my question is, In what direction do I need to go in order to overcome the above mentioned issues. Can I get away with changing the Database mapping? Or do I need to go as far as re implementing the User and Role Stores?
What I had initially planned was to re-implement the User and Role Stores using entity framework, And i could then make use if the DB first model classes and map the actual DB structure and fields to my ApplicationUser Fields. But this is where I thought I might be diving into cold waters, and i'm generally not a fan of reinventing the wheel if not necessary.
-The first thing you should do if you haven't already is to BACK-UP your current database!
You could use code first to update an existing database.
I found this walkthrough and it seemed close to the route you're on, and I'm hoping it will help solve your problem, begin at "Migrating to Visual Studio 2013".
http://www.asp.net/identity/overview/migrations/migrating-an-existing-website-from-sql-membership-to-aspnet-identity
This would create a few new tables, but not necessarily a new database.
Download Nuget packages:
Microsoft.AspNet.Identity.EntityFramework,
Microsoft.AspNet.Identity.Owin,
Microsoft.Owin.Host.SystemWeb
Enable-migrations and run a script such as this: https://aspnet.codeplex.com/SourceControl/latest#Samples/Identity/SQLMembership-Identity-OWIN/Migrations.sql
Or you could try using a reverse POCO generator found in visual studio extensions.
(My 1st attempt at writing an answer here. Tried to clarify.)
My title is a bit complex, but I will break down really simply what I am doing here.
I have an existing database with about 20 tables. I have a project that my partner has decided that we should use the old Simple Membership over Identity. This is no longer an option on the table, we have finalized that decision. WE will be creating the project in Web Forms using Visual Studio 2012 because that is what we have licenses for.
Step 1) I started a new project in VS 2012 using Web Forms and I pointed the Default Connection String at my current database and registered a few users. This created the tables I needed for membership in my SQL Server 2012 database.
Step 2) I did some relational mapping in my database connecting existing tables to the new membership UserID's where needed so that my existing tables are now related to the membership stuff.
Step 3) Here is where I am a bit lost because normally I have used SqlDataSources with Web Forms in the past. I have some experience with MVC so I would like to do things differently in this web forms project and start from Database First and import my database tables into a Data Access Layer, I'm thinking of using a Class Library for this.
MY QUESTION: When importing my EDMX for database first. Should I
A) Bring in all of the tables (Existing Tables + New Membership Tables)
B) Just bring in the Tables that are NOT part of Membership?
C) Bring in my Existing Tables and only the User and Membership table? or
D) Do you have any other idea?
My reasoning for this question is that I know that I can access the Membership stuff in the Web Forms Project but will it possibly be needed in the Class Library since my application will eventually be very User centric. Lots of tracking of user time and logins, assigning tasks and projects, permissions to that user etc.. I was leaning toward (A)
I know this is a very complex question or maybe I should say it may have many answers all due to things that I may not know yet or I have not explained fully. But I'm looking for some direction as I have never used a Class Library or Database first in this way or in a Web Forms Application.
Snapshot of Database:
You really don't need to include the Membership tables in the EF model. As you pointed out, the Membership class will handle it as long as you have it properly configured in the Web.Config file.
You should import only those tables that are related to your application.
You would only import the membership tables only if you are building a custom membership provider, which is old news by now.
At least, I personally don't do it. This also helps to keep the EF model with just what I need.
Hope it helps.
I created a login system for one MVC App based on the new Identity framework, and since I already went through all the hard work of modifying my database to match the Identity 2.0 requirements, I was wondering if it would be possible to use it outside of MVC, so I could reuse what I already created, like a login system for a desktop project that I'm working on for example. If so, can I implement the login system on a .dll that can be reused on other projects?
Yes, you could use your existing database for another application. Add the ADO.NET Entity Data Model, and point it to your database. Then, if you need to, select "Update Model from Database" and you should be all set.
Although, it may be just as easy to create your own user/roles tables. It's frustrating (to me) that Identity creates the Primary keys as strings, even though they are essentially Guids.