We have a large multi tenant business application and we want to know how Entity Framework and Authentication will fit in this design; i mean i need samples on how to use Entity Framework in this design and how authentication will be done; i see Dynamics Crm and sharepoint use Configuration(Master) Database and different databases for each tenant; how the users will be authenticated and saved;when i investigate dynamics crm configuration database, i see it contains users table; also, the tenant database contains Users table and i don't know the difference
Your question is broad and may require a lot of detail to go into. I would like to give you a simple overview.
The Entity Framework & OWIN Middleware's are one way of easing in the development effort. You choose EF when you ONLY have a object model that is similar to that of your database.
The advent of OWIN middlewares help you to easily integrate with a wide variety of authentication mechanism like Google, Facebook, Azure Active Directory etc...
Additionally, in addition to using OWIN, you will still require to build a logic around the user and tenant management systems. There will be a tenant table that contains the metadata about your tenant's [customer's].
There will be a user table that will contain your user's against tenant's. Here, each row can be identified against a tenant using tenant identifier or you can opt to use a separate table for each tenant.
The single database model is the one which is shared by all the tenant's and is belonging to the Level 4 of Multi-tenancy.
You should decide based your business specific use case whether you need to support a shared database or a dedicated database per tenant.
With OWIN, I have also written middlewares that can talk to any OAuth2 enabled IDP and get back the user into the system. It is upto the business usecases which drive the level of customization and depth of integration required and the technologies just help us achieve the same.
Please share some more specific questions or your views to discuss further
Related
Can anyone suggest best way for implementing the below scenario.
In a multitenant application where we are tied up with different vendors, based on the logged in user we need to dynamically connect to a vendor's API and fetch user information.
What is the best way to design the scenario so that in future if we tie up with a new vendor we need to make minimum changes to our code to call his APIs. What are the pitfalls to be considered in such scenarios. Any pointers to any existing pattern/practice for such implementation would help a lot.
The following is a flexible approach.
Each new vendor will be registered in a vendors table
Create a mapping for each tenant to the list of accessible vendors in a table
For each vendor, create a configuration setting in a table which gives the keys or other details required to connect to the vendor by the tenant
On login, we identify the tenant. Then we access the vendors that the tenant can use.
Once identified, we can pickup the setting for this tenant to connect to that vendor
We will be able to connect
On onboarding a new vendor, register the vendor in the application and store the data in the vendor table
The SaaS admin can then provision the stored vendor for a tenant and provide the custom tenant connection parameters if required
From this point onwards, the tenant can then consume the features of the vendor API from the application.
This approach uses database tables which will require suitable encryption mechanisms to be employed to protect the secure data at rest.
While writing a solution from scratch based on microservice approach (more specifically it is Azure Service Fabric) I came to an idea of splitting the user Identity (which is login credentials, claims, etc.) and user profile (which may contain some social info like avatar, links to social networks, birthday, etc.).
For the identity, I'm going to use IdentityServer4 (stateless ASP.Net Core) and for storing all these data I'm thinking of an Entity Framework + SQL. The profile will be managed and stored on different microservice (stateless as well) with a connection to Cosmos DB (via Mongo DB API), thus making it a NoSQL storage.
Are there any disadvantages of such an approach I'm not aware of?
You're conflating a bunch of things here. First, you have your actual "user" entity persisted to the database. There is no good reason to split a "profile" from this, as it's all just data about the user. If you're using Identity to manage users, roles and such, it was designed to be extensible from the ground up, meaning put user data on the user entity. A separate profile entity only serves to necessitate an join for no purpose.
At a higher level, once the user has been authenticated (via Identity Server), you have a principal. That principal is basically just a set of claims tied to a particular "identity" (i.e. the authenticated user). The claims come from multiple places, it could be data on the user record, roles, or even third-party claims such as when an external login account is utilized. Where the claims come from is mostly inconsequential.
Long and short, there's no reason for a separate profile entity and especially no reason for an entirely different service to work with profiles. That profile service would inevitably have to utilize a user service, so there's a hard dependency between the two: a clear sign that it's no a true separate service. In fact, this only makes the rest of your app that much more complicated as then you're having to work with both a user service and profile service depending on what piece of the user you're after.
Here is the scenario, I have a service containing many records. My service also has many users, each with the ability to create, read, update and delete records. The ability to perform these operations on each record must be controlled at the record level.
For example, user A can only read and update record 1 but user B can read, update and delete records 1, 2 and 3 and user C can perform all operations on all records.
How if at all, can this be done using Azure AD?
Obviously, using application roles is not sufficient because that gives the user uniform access rights to all records.
The tenant is also not useful because its the same for all users (in this example).
I definitely do not want to define access rights for every record individually, I would like to do something like assigning roles to a user group and then somehow assign records to the group.
Is there a standard way to deal with this type of resource based authorization?
As you correctly mention, role based access or authorization is very generic and using that, a user with specific role gets access (or gets denied access) to all resources. (If your sceanrio permits, you could make it a little better by dividing your resources into a few types and give access for 1 or more types of resources to 1 or more roles).
When trying to control access for each record individually, you will need to implement custom logic for resource based authorization. Typically applications utilize a mix of role-based and resource-based authorization driven by their requirements.
In the end it will boil down to a mapping that you need to maintain between 3 things
Resource (or a collection of resources)
Azure AD object (like role, group, individual user that is being given permission)
Permission that you're giving (understood and enforced by your application e.g. Blogs.Create permission for a Blogs application)
Relevant Documentation available on Microsoft Docs
Role-based and resource-based authorization
This documentation talks about similar concepts and shows a good example which makes use of both role based and resource based. CRUD operations on resources based on roles and then special privileges on specific resource for the owner of that resource (i.e. resource based)
Code Samples
Multi-tenant Survey Application Code
Code base for the documentation link above
Authorization in a web app using Azure AD groups & group claims
This one provides a sample task tracker application where users can share tasks with other users or Azure AD groups. Again you will see a mapping between resources (i.e. tasks in this case) and Azure AD objects (i.e. Users or Groups) is being maintained in sample database.
Assigning Application Roles for groups
Since you mentioned this as part of your question, just letting you know that this is possible from Azure Portal but only if you have Azure AD Premium license (I'm not sure which specific ones support it, but search on Group based assignments feature and you'll find it.)
Forgive me if there's already been a very similar post to this - I searched and did find "related" threads, but none that hit home, or it was targeting a different version of asp.net or asp.net core. I just need some advice and pointing in the right direction.
My healthcare organization already has/uses a few OLTP systems for capturing patient data. I'm developing an Intranet that will consume the data from the various systems and present summaries/aggregations of that data for stakeholders. I'm developing the Intranet with ASP.Net Core MVC 2.0.
Being that the data is patient healthcare information, both Authentication AND Authorization are extremely critical.
For the intranet Auth, there's no point in reinventing the wheel - don't want to create the Auth layer from scratch. The existing OLTP systems already have very robust Auth layers, with detailed User Info, Roles and Profiles. Through Data Integration, I can get that User Auth data form the existing systems, store it in SQL Server tables, and then leverage it in the Intranet.
The question is, what's the best approach to accomplish that in a concrete manner.
Again, I already have all the necessary roles and profiles, I just need to be able to reference them in MVC to be able to:
Accurately authenticate users.
Would this be best accomplished using EF in an AccountController?
Appropriately conduct Authorization (show/hide/prevent menu options, access links, pages, etc.).
Would it be possible, or is it bad practice, to map the existing user roles and profiles to Claims in MVC via a proprietary sql server bridge table?
Again, please know that I'm using ASP.Net Core 2.0... so please don't provide any example code snippets in 1.0. (The Auth architecture drastically changed between 1.x and 2).
Thank you all for your consideration and time.
I've been reading about Azure's Access Control Service and claims-based authorization in general for a while now, and for whatever reason, I still don't see the rationale behind moving from role/permission-based authorization to a claims-based model. The models seem similar to me (and they probably are), except that the list of what the client can and can't do comes from a third party and is wrapped up in some sort of token, instead of from some sort of database that the server has to query. What's the advantage of getting a third party (the token issuer) involved?
I fully understand the advantages of outsourcing authentication to a third party. It allows apps to not have to create new users all the time, worry about storing passwords, etc. when they can just push that off to some other service that already has the infrastructure set up. It's essentially the DRY principle for authentication.
However, in my mind, that same logic doesn't work for authorization. Each app has its own resources it has to protect, and therefore its own rules for authorizing users to perform certain actions. The infrastructure seems simple enough that each app could create it on its own (a table mapping users to roles, and possibly another mapping roles to permissions), and even if you wanted to outsource it, it seems that the claims-based model is doing something more complicated than that.
The only partial explanation I've seen comes from Building a Claims-Based Security Model in WCF, and it gives two main advantages to claims-based auth: more flexibility, and someone to "vouch" that the information in a claim is correct. When would you need either of those?
Claims-based authorization seems to be gaining popularity, so I assume there must be some good rationale for it; I just haven't figured out what that is yet. Can someone please provide a concrete example of a situation where claims-based auth works better than role-based, and why it works better in that case?
(EDIT: I missed a third benefit listed in the article: supporting single sign-on/federation. But doesn't authentication deal with that on its own without getting authorization involved?)
I guess the main promise of a benefit from federated security / claims-based system would be one fewer area you have to deal with different systems.
Imagine a site where you have local users authenticating with Windows credentials, a bunch of internet users using username/password, others using certificates, and maybe another group of users with biometric authentication.
In today's system, you have to set up and deal with all different kinds of authentication schemes and their different ways of doing things. That can get pretty messy.
The promise of a federated security solution would be to handle all those chores for you - the STS (security token server) would handle all different kinds of authentication systems for you, and present to you a uniform and trusted set of claims about a caller - no matter from where and on which path he's arriving at your site.
Of course, just examining and reacting to a single set of claims rather than having to understand four, five, ten different and disparate authentication systems looks like a really compelling promise to me!
The purpose of claims based authorization is to allow fine grained access control based on Boolean expressions that evaluate characteristics of the accessing entity and the resource. This reduces or eliminates the need to provision groups. As with federated identity, claims also provide a vehicle for an Identity provider to manage their users wile allowing a resource provider to gate users access to assets.
Note: Claims can be used within a single enterprise and provide the following benefits:
1) Access grants and revocations do not require provisioning or de-provisioning
2) Thus changes are instantaneous
3) Resource owners can define the scope and requirements for access rather than having admins create groups manage group memberships - this moves the access control decisions into the hands of the folks best suited to make such decisions (the data owner)
4) This results in fewer groups being required and fewer member in the groups
5) There can be issues creating a single group to accommodate a large community having access (for
example all full time employees can read a HR policy) - Claims avoids this problem
6) Audit is more informative - the reason a grant or deny took place is clearly visible
7) Claims support dynamic attributes, such as 2-factor authentication, time of day, or network restrictions
There are a lot more reasons, but those ones come to mind. There will shortly be a video at www.cionsystems.com that showcases this (disclaimer - I work there and recorded the video - I still need to post it) Also, for reference, claims aware apps and platforms include SharePoint 2010 on, Windows 2012 (file shares), Azure, many SaaS services (Facebook and Salesforce)
Also, with claims you can blend information from multiple sources (say Facebook and your local AD) etc. - which is increasingly important
Not sure if the rules allow this, but feel free to ping me with your questions or comments. I'll happily edit the post to make any corrections or add pertinent info.
Claims can come from AD, databases tables, SAML, OAuth, algorithms, XACML or any other trusted provider. Harnessing claims requires a bit of kit - with apps and platforms evolving rapidly in this space.
All the Best,
Paul
Claims-based access control also helps build up attribute-based access control and policy-based access control. If you standardize on a set of pre-agreed claims that can be assigned to users based on their other attributes (e.g. a US manager can have claim U_M; a European manager can have claim E_M).
In an attribute-based and policy-based environment, it's possible to achieve fine-grained authorization (also known as fine-grained entitlements) using XACML.
In this case, you can have authorization that depends on who the user is (claims) but also what they want to do (resource information) and under which circumstances (context).
CBAC with XACML will let you express rules like:
managers can edit notes they created themselves or notes that their
direct reports created.
Role based security is a limited security model
Authorization is:
Based on role membership only
Claims based security is much more flexible and expressive
Authorisation can be:
Based on role membership
Based on Age
Based on Geographic Location
Based on an account balance
Based on a size
Based on pre-defined securtiy levels
Based on any combination of the above