I'm part of a Facebook group for people who graduated from my high school. One of the members of the group keeps a running comment in which he posts the names and details of the former students who have died. You can look through the names, but it's not very easy to determine if a particular classmate is in the list. I thought of creating a database to hold that information but I wanted to limit access to people in the FB group. I wonder if it's possible to give access to group members through FB rather than manually adding each of them to the database access list.
Related
I am trying to build a database that stores Active-Directory entries for users/employees.
Is it safe to assume to query on: (objectClass=person)
What attribute should I store as a unique identifier that isn't the DN? e.g. should I use mail or uid
Also when an employee gets de-activated is there a new attribute that gets added or are they simply removed entirely from AD?
The question asked by you seems to be somewhat opinion based, but I'll talk it from the context of general options available in AD and the usual practices followed.
Is it safe to assume to query on: (objectClass=person)?
All the users created do come under the category of (objectClass=person). But, then if you create a generic-user for having file-share access on a system (through ADUC(dsa.msc) / powershell / C#, etc) which would not be an employee, then in this case it would violate your search condition despite being a person class. I can think of so many other scenarios where it would be impossible to avoid generic-users creation (which would again lie in person objectClass), at least from the viewpoint of mid-sized company and above.
Hence, in such cases it is better to follow a naming convention in your environment to avoid any such confusion. One sample example could be, say set the UPN/sAMAccountName for non-employee users to start from genXXXX, and you'd be easily able to search all employee users henceforth.
What attribute should I store as a unique identifier that isn't the DN? e.g. should I use mail or uid?
There are unique identifiers already available in AD like objectGUID and objectSid. In a domain, the sAMAccountName/UPN values are also unique. But, you cannot rely on that for forest-level search.
objectSid for a user can change when the user is migrated to another domain, but objectGUID never changes. You can read more about SIDs versus GUIDs here.
Also when an employee gets de-activated is there a new attribute that
gets added or are they simply removed entirely from AD?
There is no automatic trigger at AD side. There is an attribute called lastLogontimeStamp which helps keep a track when a user or computer account has logged onto the domain (not the live scenario, but recent one - depending on if it keeps updating properly).
Someone has to manually disable/delete the account if an employee/user leaves the organisation. There are process setup in companies to deal with this scenario where the Access Management solutions are linked with AD modules, and take care of the entry and exit of the users and perform relevant action in AD.
Hope it gives a rough idea of management for the queries raised by you.
I am looking for a database design that can track and manage users with attributes to systems.
Situation:
A user has access to many systems in the organization and within each system, different attributes such as date created, system login name, system user id, etc. Currently, we have a database that is a flat database so for every attribute is in one row and continues to grow as more system attributes are added. The current tool used is an Access database and the current column count is 231 columns (OMG)! This is getting out of hand.
Assumptions:
There are a lot of attributes to track and one specific table in a database shouldn't be so broad to accommodate those attributes. Creating a table for each system becomes a mess in itself because each system may change in terms of columns. We need an interface for the administrators to easily manage this.
Let me give an example:
User Sunny, who works at Google, has access to the DMV, IRS, and Whitehouse.
For the DMV, Sunny has a user name, a pin code, and authorized IP address field. For the IRS, Sunny has a tax ID number, an organization number, a clearance number, and an access expiration date. For the Whitehouse, Sunny has a user name, a password, an access schedule, a portal address, and a user type. As Sunny works at google for years and slowly things change. Sunny gets access to the NRA, HP, Facebook, and Intel. The IRS adds a department clearance information. Whitehouse requires an authorization ID. The administrators need to see what access Sunny has and looks into the system; easily they find what they need.
Conclusion
Modifying tables and adding attributes may change on a regular basis. Developing a single table to handle this seems like a chore. I need a database design that could accommodate changes like this.
Question
How should design a database to accommodate something like this?
Thanks in Advance!
PS. I asked a question that is similar to this but it was a question for a software that actually exists to do this.
In my application, I need users to be assigned to groups, and each user to have a manager (the manager, who is also a user, may have a manager as well).
The app will require queries to know the maximum depth of a certain manager (so, in other words, the length of the longest path starting from a manager down to all people managed by that person). Additionally, it will need to be able to find users who are in the same group (a group can also be a member of another group).
To this point, the entire application had been modeled with JPA in a MySQL database. However, it is designed as an SOA, so changing the underlying data store of the service that handles users (user-service) wouldn't be all that expensive.
Are there any ways of doing this that don't require a graph database? If a graph database is necessary, should I store all user information in the graph, or just the appropriate relationships?
If your basic model is
(group:Group)<-[:IN_GROUP]-(user:User)
(man:User)-[:MANAGES]->(sub:User)
you can do:
MATCH (manager:User {name:"Colin"})-[:MANAGES*]->(u:User)
RETURN u
for your second query
MATCH (manager:User {name:"Colin"})-[:MANAGES*]->(u:User)
(u)-[:IN_GROUP]->(g)<-[:IN_GROUP]-(u2)
RETURN u.name as user, g.name as group, collect(u2.name) as colleagues
You can store all user information in the graph but you don't have to. Do what's easiest for your and best for your use-case.
Without a graph database you're up to write painful heavy-JOIN SQL queries, esp. for the variable length relationships.
I have an ASP.NET MVC + SQL Server application with 250 simultaneous users daily which uses AD/NTLM SSO to do all the authorization using a custom authorization security class that control access to controllers & Actions based on users & groups.
A dilemma recently came up where the 50K+ account records of the database are going to be managed by different groups to varying degree's:
All users will be able to view most records certain records can only
be edited by certain users/groups of specific departments There will
be an admin & support groups that will be able to edit any group owned records
etc.
This is not a problem of who has access to what features/forms/etc. in the controllers, but instead a dilemma of data ownership restrictions that must be imposed. I am guessing this means I need some additional layer of security for row level security.
I am looking for a pragmatic & robust way to tackle data ownership within the current application framework with minimal performance hits since it is likely the same thing will need to be imposed on other much larger tables of data. Initially there will be about 5 ownership groups, but creeping up to 25 to 100 in the near future.
Sadly there are no cut and dry business rules that are hard and fast that can be implemented here.. there is no rhyme or reason make sense of who owns what except the record primary key id.
To try to fix it I was thinking of creating a table of owner_roles and map it to the users table then create another table called accounts_ownership that looks something like:
tbl(PK),row(PK),owner(PK),view,create,modify,delete
accounts,1,hr,1,1,1,1
accounts,1,it,1,0,0,0
accounts,2,hr,1,1,1,1
accounts,2,it,1,1,1,1
accounts,3,it,1,0,0,0
But in doing so that would create a table that was 250K lines and could easily get some crappy performance. Looking at sites like Facebook and others this must be a common thing that has to be implemented, but I am hesitant to introduce a table like that since it could create serious performance issues.
The other way I thought this may be implemented is by adding an extra column to the accounts table that is a compound field that is comma separated that would contain the owner(s) with a coded set of rights ie.:
id owners
1 ,hr,
2 ,hr,
3 ,hr,it,
4 ,it,
And then add a custom class to search using the 'like' statement.. provided the logged in users role was "it" and the comma's were reserved and not allowed in owners names:
SELECT * FROM accounts WHERE owners LIKE '%,it,%'
... however this really just feels wrong from a DBA perspective (ugly as hell) and a maintenance nightmare.
Any practical approaches on how I could implement this without destroying my site?
Start with Role-based access control, you can possibly skip the roles from the pure definition but should be able to implement it like this:
Every user can be in one or more groups like admin, support, it, hr
Every data row has an owner like it, hr
On Access, check the access: an admin can see and edit all rows. Support+it sees every row and can edit those from it etc. This way you need only (user-groups + row-access) new rows in your database, not (user-groups * row-access).
User groups in your scenario should be possible to hardcode in your application, in a CMS there is generally a table defining what rights to assign to each user group - complicating the coding but very flexible.
Roles in the original concept allow a user to select what rights he/she wants to use, there would be a "Unlock with admin rights" or the like in your interface.
Primarily for performance reasons, I went with the less elegant approach listed. It took some doing, but there are careful application controls that had to be created to enforce things like no comma's in the id's.
This is a design question.
I need to come up with a Data Model for a small app and I'm looking for the best approach.
A simplified version of the business I'm trying to model has the following entities:
Assignments: These are like projects, they have a start date, end date and a team of people associated
Workers: These are the people that execute assignments. A given worker can only be associated to one assignment at a time. Many workers can be associated to the same assignment at the same time (for big projects).
Manager: There's basically few managers in this business, who are in charge of allocating workers into new assignments as they come.
Then, there's the Web app that the Manager will use to manage who does what, i.e. which worker gets assigned to which assignment. The Workers will also use this app to register expenses associated to their assignments.
So in the context of the Web app, there will also be the User entity, and both workers and the manager will have their users to access the app.
My question is:
What's the best data model to support this (simple) system?
I picture this model:
USER (id, username, password, ...)
PERSON (inherits from user + name, email, etc...)
MANAGER (inherits from person + extra fields for manager only)
WORKER (inherits from person + extra fields for worker only)
What I don't like about this model is that every person must have a user. Maybe that happens today with workers and managers, but i will then add "customers" to this system, which will also have people associated that won't access the site, so they won't have a user.
Is there a better approach? Is there a standard approach without inheritance maybe?
Update
Ok, based on the model suggested above and completing with some extra info about this particular business, here's the (basic) model.
PERSON
id
email
passmd5
role_id
firstname
lastname
...
ROLE
id
description
PERMISSION
id
description
ROLE_PERMISSION
role_id
permission_id
COMPANY
id
name
contact_name
contact_email
ASSIGNMENT
id
customer_company_id
start_date
end_date
location_lat
location_lng
location_description
MACHINE
id
brand
model
description
PERSON_MACHINE_EXPERTISE
person_id
machine_id
Here's some extra information about the business to help understand the whole diagram:
The business consists on sending people who are experts in some kind of machinery to different locations around the world, to give service to a given customer.
There are people who are the "experts".
There are people who are the "managers" (probably just one, but there could be more).
There are assignments (a job, basically, which requires expert people to complete the job, sometimes more than one expert).
There are customers, who are basically companies, not people.
There are machines.
There's information about which person is an expert on which machine.
Makes sense? Any ideas that may improve this?
To approach this problem without inheritance you could perhaps define a Person class and a Role class, with every Person having a list of Roles (or a single one based on the needs of the domain).
The Manager and Worker concepts will then fall under a Role class, with some people having the Manager role (the managers) and others the Worker role. This will simplify the management of all Person objects as modifying their status, permissions and such being reduced to updating the role in the system. It will also give you the flexibility of adding new Roles without having to modify the source: simple create a new instance of Role, say Customer and assign it to whoever Person is needed.
Lastly, you could create a another concept, call it Permission that defines what can a Person do, with Worker and Manager roles having a CanAccessWebApp permission (and the Customer not). This will offer you a lot of flexibility in the long run while keeping the overall relationship design rather simple.