I need some advice on how best to implement a security mechanism in a ASP.net core application. The application users are authenticated using AD authentication. Is there a best practice for this type of implementation?
I have a list of project records. Users should only be able to retrieve a list of projects that they have permission to access. I have three user types that have different levels of access as detailed below.
Approvers – assigned to individual projects.
State approvers – Can view state-wide projects.
Global approvers – Can access all projects.
Does anyone have any suggestions on what model and logic to implement to achieve what is required?
Well, I secure pages with information "limited" to logged on users. So if they have membership in a particale role, then only those users can jump/see such pages.
However, in your case, and often?
Well, it not so much the web page the user can use, or be restricted from.
However, when a web page can be restriced based on IIS security and not your code, then that option should be used.
However, often in code, for example, we have indivdul users from a given company, and ONLY some can and are allowed to see all projects. (so some only can see their own projects, but from that company, some have rights to see + use all projects.
So, we often have code say like this:
Dim cmdSQL As New SqlCommand("dbo.GetProjects", GetCon)
cmdSQL.CommandType = CommandType.StoredProcedure
cmdSQL.Parameters.Add("#LogonID", SqlDbType.Int).Value = Membership.GetUser.ProviderUserKey
cmdSQL.Parameters.Add("Email", SqlDbType.NVarChar).Value = Membership.GetUser.Email
cmdSQL.Parameters.Add("#PortalMaster", SqlDbType.Bit).Value = IIf(Roles.IsUserInRole("PortalMaster"), 1, 0)
so, if the user is a PortalMaster, then they can get and see all projects belonging to that company. (each company that logs into teh site can have 1 or 20 employees that belong to the given company).
So, in above, the query going to pull projects by EmployeeID (their logon), and thus they can only ever see their own projects.
If you are a member of the PortalMaster group, then we pull projects based on ComapnyID.
So, while you might not be using the older secuirty provider like above? Your queries that pull projects simple have to restrict rows returned based on above.
Once those projects are returned (in a nice grid - searching options included), then they can select (click on) a project. that next page does not really care anymore, since you can't get to the project details page until you selected a project.
So, obvious you must have for a given Project who created it. And thus your ability to display their current projects will be restriced based on their logon ID or whtever you using now.
But, for state level users? Then your critera is by their logon id and their state they belong to based on that logon.
And then there is the "admin" role or group - they can search and pull on all projects.
So, while we do restrict web pages by "role" security (based on IIS), that just means that all users can, or cannot hit some web pages based on their role memember ship (and such security does not require code on my part - the IIS secuirty assinged to those web pages can do all that dirty work for you.
However, if you are a legal logon, then you can only ever work on projects that belong to your company. But then it is a question if that user also has the role of "PortalMaster", and if they do, then we pull all projects for display to select from for that given user.
And of course we never use say URL "query parameters", and such internal database company ID, or ContactID (user id) are never exposed, nor possible allow display of information or data that don't belong to the given user.
So, you need to build some sql or some store procedures, and having a few "parameters" for those stored procedures that returns rows of data based on their role membership is quite much how you would approach this. So in above, if the user is a portal master, then the stored procedure simple queries the data based on company they belong to as opposed to their contact id.
Now, this of course asseumes the database schema is setup, and for example, we hvae a company table, a employee table (that has their logon information), and then of course each project created has both a created by, and the company the project belongs to. So, that simple information is enough to provide the 2 levels of security.
We actually don't have a "super user" that can look at and see all projects in the system, but it actually not all that bad of a idea, since for testing, or checking a project that has some problem is a "pain" right now, since we in theory have to create a logon for that company, or get a password.
So, all logons we create belong to a given company. And thus when a user creates a new project, it can only be created under that one company, and of course a project also requires the user that created the project.
So, you simple have to restrict records returned in the page in which they can select a project to work on. IIS security, or in fact SQL server security as a general rule can't do this type of security for you - you the developer have to.
We're using Custom Claims in Firebase Auth to manage access in Firebase and allow custom UI experience.
We're now working on the User Admin part and we can't find a way to retrieve users by the custom claims.
For example, a user belongs to an organisation and have different access level - admin or user.
We need to allow the organisation's admin to see all their organisation's users.
We'd like to avoid using a separate database to manage organisation users to not double up the data.
Is it possible?
Can we retrieve all Auth users while filtering them by specific Custom Claim?
Thanks!
There is no built-in API to get a list of all users that have a specific claim.
There is an API to get a list of all users in the Admin SDK. So you could use that and then filter the users that have the claim you're looking for.
But performance of this will not be spectacular. So if listing all users with a specific claim is a common use-case for your app, you'll want to reconsider your concern about using an additional place to store the data. Duplicating data to achieve (well performing) use-cases is quite common in NoSQL.
I have a saas platform I'm building and I'm currently struggling with how to model my auth flow. The system is going to be multiple multi-tenant applications but I would like to unify user authorization & authentication. Basically, each US State will have its own web app/resource server/database and every county in that state will be a separate tenant. I cannot combine all states into one application, so that is not an option.
I would like to throw all users and their information/password into one database connected to my auth service. But each county (tenant) admin within each state (web app) needs to be able to add & manager their users and their roles. So the auth service needs to be aware of all the different tenants across each application. I also need to be able to link items created in each database to the user that created it. If I create object "X" and another user in my county views that item, they can see "Kovaci" created this.
I also do NOT want SSO between states but if possible I would like users to be a part of multiple tenants within one app (not a requirement though). Native iOS/Mobile apps are another client I need to support with this flow.
I used this bitoftech article to base off of: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/comment-page-1/#comments
And here is my paint quick mockup: multi saas design
My question is just generally how do I design this auth part? Can I store all users in one auth db like my goal? If so, how do tenant admins manage them and how do I link tables in my separate app db's to the users' current info in the auth db?
I am building an asp.net apartment rental website. Currently, I do not utilize any membership functionality so there is no need to create long-term users, manage profiles or any extensive user related data.
I, however, have a separate database that contain tables for (Units, Locations, Tags..etc) with a simple User table that contain the following three field: name, email and phone#. Note that when the offer of the unit has expired then the created user will be deleted form the database.
Putting scalability and best practice in prospective, should I create ALL the tables in one giant database (ex: in the ASPNETDB if I want to use the default asp.net membership provider) or should I keep the membership database separate from the apartment-related database?
No reason not to have it all in a single database - less maintenance over the long term.
Our requirement is something like this.
We are building a multi-tenant website in ASP.NET MVC, and each customer should be able to create their own users as per predefined user roles.
We are thinking about to create a schema for few tables which would be common for customers. So customer can login to system according to their schema logins and we need not to alter any queries to serve all of them.
We are referring http://msdn.microsoft.com/en-us/library/aa479086.aspx Shared Database, Separate Schemas.
Can someone suggest on following
1. After creating schema how to authorize user against a particular schema
2. Is this possible that without any changes in queries db can serve multi-tenants
Thanks in advance
Anil
After much research, I can say that, although it takes more development up front and more checks along the way, shared database and shared schema is the way to go. It puts a little bit of limits on how easily you can cater to a client's specific needs, but from my point of view SAAS isn't about catering to a single client's weird needs. It's about catering to the majority of clients. Not that it's a SAAS but take iPhone as an example. It was built to cater to the masses. Rather than focusing on doing everything it's built to be one-size fits all just by its simplicity. This doesn't help your case when it comes to authoriztion but it'll save you dev hours in the long run.
If you are asking this in the context of SQL Server authentication/authorization mechanism, i can asnwer this question with saying that every user has a default schema which helps query engine to find out required object in the database.
SQL Query Engine will look at the user's default schema first to find the required object (table). If it founds the object in user's schema then use it, otherwise goes to system default schema (dbo) to find it.
Check this article's How to Refer to Objects section to find out how it works. The article also has some information about security concepts related to schemas.