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.
Related
Our current API leverages ASP.Net Identity and Policy Based permissions for Authorization. It uses User Roles as claims for this. These claims are intercepted by a ClaimsTransformer class and the user permissions are read from a database containing the user mappings (cached). This all works fine.
The problem I'm having is with the API's scope expanding to include different "Projects", such that for instance, a User can be a Creator in one project but a Consumer in another. Is there a way to reconcile these requirements with .NET Core's Role/Policy based Authorization? Or is the best approach here to query the Database for these permissions upon each request?
Authorization is hard and a good starting point is to watch this video:
Implementing authorization in web applications and APIs.
Then using the policies and requirements is how I would approach this and this resource is a good reference:
Custom authorisation policies and requirements in ASP.NET Core
The picture below shows how the concept of requirements work in ASP.Net Core where you can define a requirement and then have one or many handlers independently "vote" if the user is approved or not.
Good day everyone,
I have a conceptual question regarding the feature in the title. I've been searching around but cannot find any useful information because I am either missing the concept completely or there is an overflow of examples on the internet.
The problem is fairly simple:
We have three web applications. All of these are aspnet core based and use IdentityFramework along with JWT for authentication as well as authorization. Each have their own database. Recently, a request has come up to rip out the JWT token issuing code and place it in a single separate application to be able to implement SSO. All fine and dandy.
But: each application has an extended user object that is app specific, along with claims that are app specific and stored in each individual database. We'd like to keep the basic info on the new login server (email, password, phone number... the standard IdentityUser model), while the extended info would need to come from each individual app. This way (I suspect) we could enable google log on our apps as well.
Could someone kindly either explain to me the core concept of SSO using JWT for multiple apps or at least direct me to a book/extensive article about the subject? I need a starting point.
Thank you in advance.
I'm attempting to build an ASP.NET Core API with authentication/authorization handled by IdentityServer4. IdentityServer4 is being backed by both Identity and Entity Framework Core. My goal is a fairly standard and familiar set up, where users can login into a API developer portal where they can add "applications" (clients) and have a client id and client secret generated that they can then use to access the API, similar to how Facebook, Google, etc. handle API access.
My mental block is coming with the way IdentityServer handles Entity Framework integration. Their entities are attached to two different contexts, ConfigurationDbContext and PersistedGrantDbContext. I'm at a loss for a good way to associate one or more Client entities from IdentityServer4.EntityFramework with one or more ApplicationUser entities from my Identity context.
This seems like it would be a fairly common usage scenario, but the documentation is strangely silent on it. I've also been unable to find anything online after various and sundry searches. I'm hoping someone else has needed this same setup and can give me some advice on how to proceed.
There is no association between users and clients. IdentityServer authenticates users regardless of which client they are trying to access.
If you want to implement something like "which user is allowed to use which client" semantics, that is beyond authentication. This is typically implemented in the application itself since this is application specific logic.
https://leastprivilege.com/2017/07/10/authorization-is-hard-slides-and-video-from-ndc-oslo-2017/
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
The new ASP.NET 4.5 code has "re-parented" the ASP.NET RoleProvider to a ClaimsProvider.
What I'm trying to figure out, is what would a "claims based" example of authorization look like (preferably in MVC4)? How does my Authorize attribute interact, or not, with this capability? The WebSecurity and Roles API havn't changed; there is no "DoesUserHaveClaim()" signature. Similarly, it is not clear how the Authorize attribute interacts with claims.
Was this "claims authorization" feature intended primarily for OAuth? If so, how are claims forwarded to my application? A cookie? Or was this claims-provider functionality intended for a broader use?
In short, what is the story for using a ClaimsPrincipal?
The closest thing I've seen to something that kinda makes sense, is this discussion. But I suspect that is dated - it should be compared to what the MVC4 internet project template produces. And even then, it still did not suggest how to use the Authorize attribute with the setup.
UPDATE
I've found the answers to my questions from these sources:
The remarks section of ClaimsPrincipal explains that WebSecurity, Roles, and AuthorizeAttribute APIs do in fact boil-down to claims checks as necessary.
A claims-based MVC4 example is here (along with others).
The basic SAML story is shown here.
Claims-based security helps decouple your security model from your application domain. A claim can be anything you want to attach to the identity of the user, such as an email, phone number, or flag indicating whether the user is a super user. This gives you the ultimate flexibility on how you want to setup your authorization process. Historically in an ASP.NET application you have to determine what roles you want to allow and apply them when programming your application. Then you check if the user is in the role to authorize them. This mingles your security model with your application. In claims-based you have much more flexibility and it is more typical to setup an authorization scheme that takes a resource (ex: Orders in an order management system) and an operation (ex: read, write, execute) as input parameters to your authorization process, effectively decoupling security from your application. See ClaimsPrincipalPermissionAttribute for an example of this technique.
Claims-based security is required with OAuth but it works well with other authorization schemes as well. The custom claims you use in your application are accessible from ClaimsPrincipal.Current. There are techniques to store this information in cookies as well, although the ASP.NET security pipeline does not do this by default.
The discussion you reference is for Windows Identity Foundation (WIF) which is now part of .NET in 4.5 and is why claims-based identity is a first class citizen. All of the Principal types inherit from ClaimsPrincipal. For a good overview of claims-based security look at this free ebook "A Guide to Claims-Based Identity and Access Control (2nd Edition)". A real expert in this area is Dominick Baier and his blog is chocked full of useful information on this topic. He also has a great online training course on Pluralsight called "Identity & Access Control in ASP.NET 4.5".