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.
I would like to use Symfonys API platform for a BI application. I know it is great in security and flexibility, but I need something I have not yet found in documentation or here on stackoverflow.
I have multiple databases and each db contains data of multiple customers.
Now I want to limit which customers a logged in BI user can see. If a BI user is limited to see only data of a subset of customers (that relation is present in the DB), how can I make sure this user will only see data related to those customers, and not any other?
I could use a customer ID as entrypoint, would since it should contain data of all customers and the list of customers is dynamic, this will not work.
I know there must be a way to have that security on kernel level/Event Listener but was unable to find this.
Thanks in advance for any help!
So I'm looking at setting up Google Analytics (GA) for the first time. My app will have three environments (initially):
Dev
UAT
Prod
w.r.t GA I was curious as to whether best practice is to:
Create 3 distinct GA accounts; 1 for each env; or
Create 1 GA account and somehow keep the data separate
According to this accepted + upvoted answer, it sounds like the latter is the preferred way of managing GA across environments. And that the solution is to add filters/views to your configurations so that data from each envrironment gets filtered/routed to the correct environment-specific reports.
My only potential problem with this solution is that I need my developers to have access to the dev data in GA, product & QA to have access to the UAT data, and only a handful of key business/marketing folks to have access to the prod data. Devs should never have access to UAT or Prod data, etc.
I took a look around GA's permissions documentation and I don't see any way of granting users access to specific filters/views. Anybody have any idea how I could create a "Developer" role inside GA and only grant read access to filters/views/etc tagged or marked as being part of the development env?
Otherwise I'll need to sadly create 3 distinct GA accounts, one for each env :-/.
My GA setup is very similar to yours. I have a single GA account that has multiple properties such as web-dev, web-stg, web-prd, mobile-stg, mobile-prod, etc. Each of those properties have a minimum of two views. The first view I title 'Raw Data' as no filters should ever be set on this view to have access to the raw data collected by GA. My second view I call my 'Filtered View', which is the view I look at 99% of the time. In the filtered view, I exclude company IPs, bot IPs, vendor IPs, etc.
To answer your question about access to each property and view, they can be set on any level from the admin menu under the user management option.
We are developing an intranet application using the Business Connector with our Dynamics AX 2009 installation.
We want to allow users to update the data from certain tables if the user already as permission to do so in AX. That is, if the user's effective permissions would allow them to update data using the AX Windows client, then they should be able to update the data using the intranet application.
We are using the LogonAs method and passing in the current user's logon name. That all works. But, for users that ARE ALLOWED to save data, I want to show an update button. For those that are NOT ALLOWED, I don't want any button to show.
Is there a way to query a user's permissions for a given update without trying to perform the update?
Have a look at the static method Global::hasTableAccess(tableId, AccessType)
So a call like
hasTableAccess(tablenum(SalesLine), AccessType::Edit)
would check whether the user has sufficient rights to edit that table - in this case SalesLine
Via CallStaticClassMethod you can call it directly passing both arguments or write a simple thin wrapper in X++ with a new class which just accepts the table name and calls this method with proper values on your behalf - the latter having the benefit of not exposing the raw numeric table ID and enumeration value which may change in a future version.
What is the best way of implementing a checkout process that allows customers to place orders without first requiring registration on the site, and without requiring that users create an account during the checkout process.
I was thinking of perhaps creating a anonymous customer entry which all orders not associated with a registered customer get associated with. Will that work?
How would you then recommend accessing order status?
Well the easiest way to do this is to create an account for the user as they checkout. You can generate a password for them to comply with the existing model, and depending on how you want to handle these users you could also flag the record as a "temp" user. You can then remove these users as time expires. These approach gives you the flexibility of also asking the user to create an account after they have successfully checked out; you'd be surprised how many users are willing to just enter a password when thats all they have to do to create an account.
The key here is to make sure you use a unique id for these users as opposed to the email address; otherwise you will run into an issue when the same customer comes over to purchase again within the period where the user still exists.
There are multiple ways of doing "Guest Checkout"; it depends on how much work you want to do upfront and what your long term goals are.