How role based ACL should be designed for :
Multiple teams, each team consisting of one manager and multiple members and working from one location. Each location could have multiple teams and there are multiple locations.
Manager of each team could only view/edit data for his team members. A person could also be member of multiple teams, independent of location.
Location_1
-Team_1 -Team_2
-Manager -Manager
-Member_1 -Member_1
-Member_2 -Member_2
Location_2
-Team_1 -Team_2
-Manager -Manager
-Member_1 -Member_1
-Member_2 -Member_2
My thought: I'm thinking of separating it in two parts. Part 1: There should be one group for each team. Maintain table of group membership in database. Part 2: Now, each user can have any role. And ACL could be designed based on those roles. But data would be fetched based on Part 1. this way new teams could be added without change in code. Is this a right way to go?
Kind of a fairly chatty answer here, loose discussion only, no code, at least for now.
Your own model/data structure has to consider members, locations, and teams. I think you have described the relationships pretty clearly, so that should be straightforward. Thinking relationally: a table for team members, including managers; a table for locations; a table for teams with a foreign key into locations and a foreign key into members identifying the manager; a cross-ref table linking members to teams. I assume your member model will have methods for isManagerOfTeam($team), isMemberOfTeam($team), stuff like that. Pretty straightforward.
But much of this is just modeling the relationships, arguably independent of access-control.
For access-control, it appears that location is irrelevant; it's team membership and team management that are the key.
It also sounds like the data you are trying to access-control (what will eventually be the 'resource') will be tagged with a member id, identifying the "owning" member. So, the model for that data might have a method getMember() or even just getMemberId().
So I see some Acl rules that use a Zend_Acl_Assert_Interface instance to make dynamic examinations on the relationships between the role ($member) and those resources:
My_Acl_Assertion_BelongsToSelf
My_Acl_Assertion_BelongToMemberUnderManagement
Then the assert() methods could call the relevant model methods on the passed role and resource to check the team and management relationships.
Like I said, kind of a loose answer, but hopes it helps with some ideas.
Related
I want to create a project with multiple classes but not sure how to properly connect them together.
Let's say our model consists of following classes. Sports leagues consists of multiple teams, teams consists of players and a manager. Let's say I want to connect players to a specific team and a team to a specific league.
I can add to a League class list of teams and to a Team class — list of Players and "Manager" property like that:
class League {
private List<Team> teams;
}
class Team {
private List<Player> players;
private Manager manager;
}
With this kind of "top-to-bottom" model we can easily construct league tables or get team rosters. But what we cannot do with this model is to take a player and find his manager or team-mates. And we can't find a position of a concrete team in a league because only league knows this information, but Team is unaware of what League it has been appointed to. One the other hand I can use "bot-to-top" approach and add property "Team" to a Player and "League" to a Team, but now we cannot easily create league tables since League doesn't consist of teams anymore.
I can make both kind of connections simultaneously and add "private League league" to a Team and "List teams" to a League. But it's kind of a making a job twice and that is not good either. Let's say I want to store both of them in a database and I certainly can't this properties to a table since they duplicate themselves.
So what is general principle of making classes dependent on each other? Maybe I should make another support classes to maintain connections between them? What kind of principles describe this kind of a problems? What should I read to better understand this dependencies?
I consider the solution of implementing bidirectional dependencies to be the best for this particular scenario. There will be two main drawbacks though:
You would have more memory usage.
You would have to consistently update dependencies if there's any modification.
This will depend on the solution you are trying to implement. If you are expected to perform queries and so on, then it's fine, given that the utility it brings is way better than the issues it might cause. But if you are not planning to query the information that much, then I'd rather pay for the lower performance rather than maintenance and memory usage.
I work in cattle production and I am learning about database design with postgreSQL. Now I am working on an entity attribute relationship model for a database that allows to register the allocation of the pastures in which cattle graze. In the logic of this business an animal can be assigned to several grazing groups during its life. Each grazing group in turn has a duration and is composed of several pastures in which the animals graze according to a rotation calendar. In this way, at a specific time, animals graze in a pasture that is part of a grazing group.
I have a situation in which many grazing groups can be assigned to many animals as well as many pastures. Trying to model this problem I find a fan trap because there are two one-to-many relationships for a single table. According to this, I would like to ask you about how one can deal with this type of relationship in which one entity relates to two others in the form of many-to-many relationships.
I put a diagram on the problem.
model diagram
Thanks
Traditionally, using a link table (the ones you call assignment) between two tables has been the right way to do many-to-many relationships. Other choices include having an ARRAY of animal ids in grazing group, using JSONB fields etc. Those might prove to be problematic later, so I'd recommend going the old way.
If you want to keep track of history, you can add an active boolean field (to the link table probably) to indicate which assignment is current or have a start date and end date for each assignment. This also makes it possible to plan future assignments. To make things easier, make VIEWs showing only current assignment and further VIEWs to show JOINed tables.
Since there's no clear question in your post, I'd just say you are going the right way.
I've read through a bunch of tutorials to the best of my ability, but I'm still stumped on how to handle my current application. I just can't quite grasp it.
My application is simply a read-only directory that lists employees by their company, department, or sorted in alphabetical order.
I am pulling down JSON data in the form of:
Employee
Company name
Department name
First name
Last name
Job title
Phone number
Company
Company name
Department
Company name
Department name
As you can see, the information here is pretty redundant. I do not have control over the API and it will remain structured this way. I should also add that not every employee has a department, and not every company has departments.
I need to store this data, so that it persists. I have chosen Core Data to do this (which I'm assuming was the right move), but I do not know how to structure the model in this instance. I should add that I'm very new to databases.
This leads me to some questions:
Every example I've seen online uses relationships so that the information can be updated appropriately upon deletion of an object - this will not be the case here since this is read-only. Do I even need relationships for this case then? These 3 sets of objects are obviously related, so I am just assuming that I should structure it this way. If it is still advised to create relationships, then what do I gain out of creating those relationships in a read-only application? (For instance, does it make searching my data easier and cleaner? etc.)
The tutorials I've looked at don't seem to have all of this redundant data. As you can see, "company name" appears as a property in each set of objects. If it would be advised that I create relationships amongst my entities (which are Employee, Company, Department), can someone show me how this should look so that I may get an idea of what to do? (This is of course assuming that I should use relationships in my model.)
And I would imagine that this would be the set of rules:
Each company has many or no departments
Each department has 1 or many employees
Each employee has 1 company and 1 (or no) department
Please let me know if I'm on the right track here. If you need clarification, I will try my best.
Yes, use relationships. Make them bi-directional.
The redundant information in your feed doesn't matter, ignore it. If you received partial data it could be used to build the relationships, but you don't need to use it.
You say this data comes from an API, so it isn't read-only as far as the app is concerned. Worry more about how you're going to use the data in the app than how it comes from the server when designing your data model.
I'm using ASP.NET MVC3 with Entity Framework 4.
I am using the Unit Of Work + Generic Repository pattern.
I searched for similar question everywhere, I see that many people have my problem, but still can't find a good and practical solution.
We have a multi-tenant database.
Imagine a database with a similar structure:
customers
groups, associated to a customer
users, associated to one or many groups
And then, for each customer we have
resources, associated to one or many groups, and linked between each other with foreign keys, many-to-many relationships and so on
So, when a user logs in, he is associated to one or many groups, and he needs to have access to the parent and child resources associated to that groups.
Now the problem is:
I implemented a sort of pre-filtering with a .Where() clause into the unit of work, in the repositories, based on the id of the logged in user.
And this is working.
The pre-filtering I did on the repositories is working fine, but of course it works only if you access directly the repository of the sources of TYPE A or TYPE B or TYPE C and so on.
But a resource is linked to other resources with many-to-many tables and foreign keys.
So, it happens that sometimes a resource belongs to a group to which the user has access, but sometimes the resources linked to this resource belong to a group to which the user does not have access.
If I traverse the navigation properties of the "parent" resource, the user can access all the linked resources, even the one belonging to other groups.
So, if you are starting from a TYPE A resource, and traverse the navigation properties to reach the TYPE B and TYPE C resources, they are not filtered.
If you access the TYPE B and TYPE C repositories, they are filtered.
Now my filters, as I said before, are in the Unit Of Work class, but I tried to move them into a custom DBContext, applying the filters directly into the DBSet, but nothing changes:
It seems that EF is accessing directly the database to build the navigation properties, thus not using the other repositories or the other DBSet, avoiding the prefilter.
What can we do?
I see that NHibernate has Global Filters that could accomplish my task, so I'm evaluating a migration from EF to NH.
I see that many other people is asking for .Include() filters, thus disabling lazy loading.
Thank you.
I can provide some piece of code if needed, but I hope I explained my problem correctly.
Thank you i.a.
Best Regards,
Marco
I saw a solution with mapping to views and stored procedures, but I'm not sure how hard it was in development and maintanace. In short, it is possible to map EF model to views, where data will be filtered; in this solution each user have own database credentials.
I'm attempting to use the Simple Membership Provider with MVC 4 as "by the book" as possible. Here is the current scenario:
-- I've been using Jon Galloway's blog post on the topic here.
1) I'm aware this thing is wired via Entity Framework. I did notice, however, that when I added properties to the UserProfile class, they didn't appear in the table automatically when it was generated. Is this due to the database already being generated (tables were not present)? I manually added the fields and it was functional, but would be nice to know the "gotchas" that would result in the fields not being automatically created.
2) As far as the roles, it seems that it is geared primarily towards a global permission type thing (ie user is a User, Admin, etc.). In the event that you want to make it handle at a project level (ie admin for project1, user for project2), what modifications need to be made?
etc) Is there an article that really goes into detail in regards to best practices on how to extend it?
1)I find the UserProfile table part of Simple Membership a little complicated (in a good way), but it has worked great for my apps.
The convention for Simple Membership is to create a UserProfile table named "UserProfile" with two fields, UserId and UserName. You can configure a different table name or different UserId and UserName field names for the UserProfile by modifying the WebSecurity.InitializeDatabaseConnection() line in Filters/InitializeSimpleMembershipAttribute.cs. You can create a UserProfile table with additional fields and it will be used by Simple Membership if Simple Membership finds that table the first time it runs. Under the default configuration, the first time your app runs SimpleMembership will create the database tables including whatever UserProfile table details specified in Filters/InitializeSimpleMembershipAttribute.cs.
So, the trick is to create the UserProfile table you want (including all the fields you want in that table) before the first call to Simple Membership. This could be created by EF Migrations or created by a database script or even created manually in SSMS.
If you want to dig into the Simple Membership code, see http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/5cb74eb3b2f3#src/WebMatrix.WebData/WebSecurity.cs and http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/5cb74eb3b2f3#src/WebMatrix.WebData/SimpleMembershipProvider.cs.
2)I agree with your point about roles and global permissions. Maybe you could use AddUsersToRoles and RemoveUsersFromRoles (in http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/5cb74eb3b2f3#src/WebMatrix.WebData/SimpleRoleProvider.cs) to modify a user's roles at login according to the project they use.
etc)I don't know of a good article on extending Simple Membership, but in principle Simple Membership extends the Extended Membership Provider which extends ASP.NET Membership Provider. You should be able to jump in at an appropriate point.
EDIT in response to Robert's comment:
As a direct answer to why Entity Framework did not create the columns added to the UserProfile class, this happens when the UserProfile table was already created by the SimpeMembership initialization before the app-specific table creation ran. The reason is SimpleMembership has an inbuilt definition of the UserProfile table that is used anytime SimpleMembership creates that table. The timing of the UserProfile table creation is important, so there is a need to make sure the app-specific tables are created before the SimpleMembership initialization runs.