This question is an extension of my previous question. The prior question uses a similar approach but only uses active directory to populate cookies or session variables, which is useful only for simple things like populating a dropdown. Here I am extending that approach to populate a database table. The extended approach provides a technique for securing data in by creating joins in the database.
Please comment on whether this is a "good" approach to securing database data through active directory.
Scenario Need to create an application for submitting & viewing accidents reports that will be used by 50 schools. The application needs a security mechanism to prevent employees from viewing data that is not in their school(s). Some employee's are to be assigned multiple schools. The IT department wants to create a security group for each school in Active Directory to control access to the application and it's data.
Problem with Active Directory
If not using Active Directory I would simply create a database table called UserSchool which would store the username and SchoolID. This would make it very simple to write queries that return data only pertinent to user's school. I would just have to add a join to the UserSchool table in my stored procedures.
Possible Solultion This solution is an attempt to gain the best of both worlds. Security will be managed through Active Directory. When an employee logs into the application the UserSchool table will be populated from Active Directory.
Create an OU in Active Directory called AccidentReportingSchools.
Create a security group for each school in the AccidentReportingSchools OU.
To each security group, add an attribute called SchoolID which corresponds to the primary key of a table called schools.
Create a table called UserSchools that will have an Username and SchoolId field.
When an employee logs into the application a delete statement such as DELETE FROM UserSchools WHERE UserName = #UserName.
After running the delete statement the table would be populated with their UserName and SchoolID which will be taken from the Active DIrectory security groups.
Related
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.
For history, I just recently wrote this question:
This has led to a follow up question. In the User Profile, "Roles" Tab (which I'm assuming is a table somewhere), is there a table I can report on that will get me what was changed and possibly by which user account (and maybe even the IP address of the user account)?
The path is:
Main Menu->PeopleTools->Security->User Profiles (and then the 'Roles' Tab).
Ultimately I need to figure out what change was made (when a role name was added) and by what user account and as of what date/time. If possible I need to link it to the IP address (which I think is found here: PSACCESSLOG).
what you need is audit on the PSROLEUSER table: you need to build an audit table for it and fill it either by a database trigger or through a PeopleSoft development: adding record audit to the PSROLEUSER table.
The PSROLEUSER table stores the roles a user is assigned. By default there is no history. To get that you would need to enable auditing, either record auditing through App Designer or setting up database trigger auditing. The database trigger audits can actually capture changes made either online or through the database so could be considered more complete, but can take some effort to get working properly. However, the database triggers also allow capturing some additional user information at the time of the transaction.
See http://peoplesoft.wikidot.com/auditing-user-profiles, particularly the section on using the the GET_PS_OPRID functions for Oracle or the SQL Server equivalent. Capturing the OSUSER and IP here would more reliable than trying to tie back to PSACCESSLOG.
I'm setting up SQL access in a newly created OpenEdge 11.5 database.
In checking the contents of the sysdbauth table using "select * from sysprogress.sysdbauth", I see that there are two users setup by default: sysprogress and a user with the name of the Linux user account that was used to create the database.
I'm looking for recommendations as to how to handle these two accounts. Obviously I want to have an account to use for DBA tasks. Should I use one of these accounts for the purpose? If so, what should I do with the other account?
Is it possible (and safe) to be deleting either of these predefined accounts?
On page 175 of the Database Administration guide you can read about default users and why they are created:
Tables used from SQL only
An SQL database administrator (DBA) is a person assigned a sysdbauth record in the database.
SQL DBAs have access to all meta data and data in the database. To support internal schema
caching, every OpenEdge database begins with a DBA defined as "sysprogress." However,
OpenEdge restricts the use of "sysprogress."
When you create an OpenEdge database using the PROCOPY or PRODB commands, and the
database does not have any _User records defined (from the source database, for example), then
a DBA is automatically designated with the login ID of the person who creates the database. This
person can log into the database and use the GRANT statement to designate additional SQL DBAs,
and use the CREATE USER and DROP USER statements to add and delete user IDs.When creating
users, this DBA can also specify users as SQL-only users, who can only access the database
through SQL.
There are several knowledge base entries around the task of deleting or disabling the default users.
http://knowledgebase.progress.com/articles/Article/P5094
http://knowledgebase.progress.com/articles/Article/P161411
This suggests that it's really safe to delete or disable these accounts but you should:
1) Create replacing accounts first.
2) As always: test in a separate environment first and not in production!
Yes, in fact Progress kind of expects you to do so. Create a root account and get rid of both. It's fine.
I'm constructing a website.
In this website, people will be able to manipulate several DB tables data.
Everytime someone wants to make a CUD operation I want to log it (like and audit).
The way I see it, I should use triggers for CUD operations, but I can't understand how do I log the user, since triggers don't accept any input parameter.
NOTE: the user I want to log is the network user. I know this user when they access the website (user to log <> user logged to DB).
ANOTHER NOTE: None of my tables saves creation date, creator, update date and updator. Just don't know why they should when I have the audit tables.
So this is the basic problem with web apps. If you have a huge user base ( more then say 500 ), then provisioning them in the database, while this is very easily doable, it is something most web programmers, sadly, don't want to deal with and want only ONE connection user for the database. You have already shot yourself in the foot because you don't have the created_by,modified_by, created_date, modified_date in the tables. To fix this you really only have one choice:
Put the columns on the tables and force the UI people to push the "network" user name through. The rest of the columns can be handled by one very simple trigger.
Why DB audit will not help you:
The DB audit feature ONLY deals with users defined as actual users in the database, sorry that is just the way it is.
Here are some things to look at when dealing with a front end system.
You can write SP's or Packages that execute as the schema owner, but can be run by ANYONE who is defined in the database and those can handle all the INSERT, UPDATE, DELETE operations on the schema they are defined in by simply giving other users the EXECUTE privilege on that set of SP's. This give the DB fine grain control over how tables are manipulated and you only have to grans the select privilege to all the users.
You can write a SP or Package in the SYSTEM schema that allows a group of people to provision users on the system by granting the execute privilege on that SP. Within that SP you define what ROLES they are assigned and therefor can control all their access.
I have 2 questions.
I am developing a ASP.NET web application that uses the standard ASP.NET membership. We intend to have the membership tables in 1 database. We have 2 other databases that stores data for 2 different applications.
Shared - Membership info
DB1 - Application1
DB2 - Application2
Both applications uses the membership info in the "Shared" database.
The Shared database has a table called userdetals that will store additional users' info such as name, phone and job title for example.
However, DB1 also has a table called employees that store the same fields as name, phone and job title. Each employee may be an user.
Also for each table in DB1 and DB2, we keep audit trial, i.e. which user updated the tables in the database. Hence, we need to store UserID in the tables of DB1 and DB2.
We thought of having a Users table added in DB1 and DB2. So everytime a new user is created in Shared, the same user will be created in Users table in DB1 and DB2.
Our questions are:
What is the best way to maintain database integrity given the above setup? E.g. Each employee is assigned as an user. If any fields in DB1 such as username, name and phone is updated, then the same fields in Shared DB should be updated and vice versa.
Is it advisable to have membership database in a different database in our case? What is the best solution since almost all the tables in DB1 and DB2 references userID in the Shared database.
1.
The technology you are looking for is Merge Replication (http://bit.ly/KUtkPl). Essentially, you would create a common Users table on both databases, create a Merge Replication publisher on one application database, and then create a Merge Replication subscriber on the other application database. You could also set this up to synchronize the schema as well (which also means you only need to create the table once on the publishing database: it will push the table, schema with data, to the subscriber).
But if you are looking for more of a manual approach, I would not denormalize the user data to the employee(s) table, instead create a supplemental table and a view on each Application server. Kind of like inheritance in OOP: Any common data between the Employee table and Users table, leave on the shared user table. Any unique columns for the Employee, add to the supplemental table only and store on each database. The view would merge both the supplemental table and shared table. (http://bit.ly/9KPxt0)
Even if you do use Replication Services, I would still use this view design with the synchronized table.
You COULD update through the view, but I would not recommend that. It has been done before successfully in production, but there are too many constraints that could blow up (http://bit.ly/LJCJev). Instead update the table directly that holds the data.
Absolutely avoid "triggers that synchronize". Too risky (can cause an infant loop on your SQL server) and too much maintenance overhead.
2.
I would do the Merge Replication, it is just less for you to worry about and maintain after it is configured correctly. But your approach is OK if want something more manual or if you are not familiar with Replication services in SQL... just use the view noted above and you'll be set.
Easy way:
You can create link server to these databases.
And then create synonym to easy access to tables of each database.
Create trigger to update data when any data was updated on each table.