I'm developing a Multi-tenant solution and I want to use the latest ASP.NET Identity framework specifically the Entity Framework implementation.
Basically I need to allow two users to have the same username, though it must be unique within a tenant, I'd also like to make use of external sign-ins such as Twitter, Microsoft, Facebook and Google.
From what I can tell, the framework was not designed with multi-tenancy in mind, though it does seem to allow extensibility. I'd prefer to make use of as much existing components as possible, though at the moment I think I'm going to have to abandon the Entity Framework implementation, and code it all myself.
Has anyone else tried this and how much have they had to code themselves.
I've now got a working solution that I've shared in a GitHub repository:
https://github.com/JSkimming/AspNet.Identity.EntityFramework.Multitenant
The extensibility required to support multi-tenancy is not possible with the 1.0.0 release of Microsoft.AspNet.Identity.EntityFramework (at least not without a lot of custom work), but is available in the 1.1 alpha release currently available through the Nightly ASP.NET Web Stack NuGet Packages.
I've decided to release what I've produced as a NuGet package AspNet.Identity.EntityFramework.Multitenant, as stated it currently requires the Nightly ASP.NET Web Stack NuGet Packages.
I've provided two simple sites that make use the package to allow for multi-tenancy:
Vanilla Implementation which is the standard MVC5 template project that uses a string primary keys.
The changes necessary to provide multi-tenancy have been isolated to this commit.
Integer Primary Key Implementation which is making a few more customisations to use integer primary keys
The changes necessary to provide multi-tenancy have been isolated to this commit.
I plan to update the solution as the 1.1 version of ASP.NET Identity is released.
I hope others find some use in the nuget package I've released, any feedback is more than welcome and please raise any issues you find.
Update
The solution has now been updated to use the 2.0 release of Microsoft.AspNet.Identity.EntityFramework.
Yeah we explicitly left this as an extensibility scenario. You should be able to do this via overriding UserManager properties and implementing your own custom IUserStore. Although you might be able to extend the EF UserStore potentially as well and just add a tenantId to your user.
Related
Can FHIR .NET API be used to create resources from USCORE / CARINBB profiles?
I know we cannot use partial class concept unless we fork the code and change it, So, How to create profile objects within .NET API so I can post to FHIR Server?
US Core and Carin BB simply constrain the allowed values for certain resources. The resources themselves are the same. So a US Core Lab Observation is still an Observation - and can be created using the .NET API like any other Observation. There's no mechanism in the .NET API that exposes a US Core or Carin-BB specific API that automatically enforces those constraints. However, you should be able to use the .NET API to validate an instance against one the profiles from those IGs so long as you load the IG package into memory.
Summary: My task is to decide how the user authentication should be implemented for the cloud-based project that should be evolved from the older WebForms application. I am at the beginning of the decision process, but I have to decide soon; so, I will appreciate your experience.
Why WebForms? The application is based on the older WebForms code, this way it should start from the WebForms code. The problem is that the application should be ready rather quickly, so the code must be reused as much as possible. Also, we do not have developers that have working knowledge with MVC. Some trade-offs are necessary. However, the log-in process will be new, and it can be implemented using the MVC approach.
What is new: The older code was built to run on the intranet web server, the users signed-in using simple login names. Security things were not that complex. The application uses the pre-ASP.NET Identity -- really old, and that part of the application should be replaced. There will be more groups of users that should work in the separate workspace (think of companies).
New acount -- authentication: The user should use valid e-mail address to ask for registration. For the new user, the e-mail should be validated as existing, and then it should be approved by the administrator dedicated for the group.
Authorization: A user will be allowed to work only with some data. Think in terms of using a single database where the user of one group should be allowed to access only the part dedicated to the group. However, there may be power users that may have more rights.
Should I focus on using ASP.NET Identity? If yes, (not being dependent on the older versions) should I start with ASP.NET Identity 3 that is currently in 3.0.0-beta7 (see https://github.com/aspnet/Identity.git), or should I stick with version 2?
ASP.NET Identity is Microsoft's main thrust for identity and membership and their newest identity library. If you are concerned about continued support then this is the library for you.
The ASP.NET Identity library supports your need for claims based authorization (in your case using roles/groups) and recording email addresses confirmation. This is available out of the box.
I would not recommend using ASP.NET Identity 3 however, as this is designed with ASP.NET vNext in mind, not something you want to do with your legacy system.
Stick with ASP.NET Identity v2.x
I put together some code for accessing CRM using the DLL's provided in the SDK download and tried out both the early binding approach and late binding approach.
What I'd like to do is in addition to having some custom entities that my users will access in Dynamics (through the Dynamics UI in the cloud), I also want to build some Android apps that talk to Dynamics.
My understanding is that I can talk to Dynamics from Android via REST (assuming I properly handle the authentication and getting tokens using ADAL libraries since my Dynamics instances run on the Microsoft cloud) or I can use the SDK with .NET as a middle-tier.
What's the recommended approach? Is there a best practice? When would I use the DLL's provided in the SDK and maybe wrap them in my own Web API vs. connecting to Dynamics directly via REST?
Please help this noob.
Kind of hard to say, depends on your talents and needs. Here is a great website link to get started though:
http://blogs.msdn.com/b/crminthefield/archive/2015/01/12/build-your-own-crm-mobile-app-s.aspx
Just a note on the Rest calls, you can only perform CRUD operations by default, and will need to jump through some hoops to perform the other calls.
I currently developing a multi tenant saas application using asp web api. The api will be published and consumed by 3rd party application. My question is regarding versioning. I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api. I also have to update the old api to adapt to database change. That seems like a lot of work. How do big companies solve this problem?
There is no easy way around this; you will have to do the work to support old versions as long as your customers are using them.
Adopting a RESTful approach in the first place, and avoiding 'fat controllers' may help reduce the pain but beyond that every old API call will need to call into your new service layer and will need to return the results in the format your clients expect.
I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api.
No one, absolutely no one has researched, built, versioned and maintained APIs more than NetFlix - not externally but internally. They used explicit versioning (e.g. URL) in their APIs and maintained multiple versions of the same API and got their clients move along by providing incentives (new features). This is also something that can be built into your SLA, e.g. you guarantee support of particular version only for 12 months.
This is a very controversial topic and you will hear people suggesting implicit versioning (e.g. by media type etc). Feel free to listen to those but pragmatism favours explicit and purism favours implicit.
Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.