In real-world enterprise web applications for enterprise businesses, we always need to limit the access to the data by the user's unit and role.
Consider that we have an enterprise company with many shopping stores in a country.
So the company has headquarter which has view access to all invoices and statistics for all branches. Each region in the country manages and plans the regional sales strategies for its own branches. Then the region's user also can see the all invoices which have been created by its branches. Each branch can create invoice, customer, and view only its data.
We can see that we have two main access control definitions:
1- Roles (which has been thought and implemeneted many years ago!): we can easily implement using RoleProvider and controlling the access control in UI level (web.config and sitemap.config)
2- Units and its relation with roles to deny/grant the user access to update/view data.
I have implemented a custom principal in ASP.NET to get the user's unit and roles, but I think there should be a classic solution...
Check these out:
http://netsqlazman.codeplex.com/discussions/352107
http://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/
Here is MY explanation.
http://granadacoder.wordpress.com/2010/12/01/rant-hard-coded-security-roles/
............
The MembershipProvider is based on ROLES,....and that is for your kid's soccer club...NOT a professional DotNet application.
There is a "middle ground" workaround.
http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
Basically. Use the MembershipProvider......but treat the word/phrase "Role" as "Right". (In your mind..you cannot change the names of objects in MS code of course)
Rocky's NUTSHELL ( from url above)
bool result = currentPrincipal.IsInRole(requiredPermission);
Related
We want to move our entire IT side of the business onto firebase but need to find the right architectural approach before we do so.
Here's our company and business setup:
one company with one domain i.e. example.com
several business areas independent from each other. For example: one sells bananas, another one is about facility services, yet another one about local transport services & repair
the same customer can be customer to one or more of those business areas i.e. we have centralized billing, centralized auth with SSO, centralized customer relation management etc.
every business area (e.g. selling bananas) has a web as well as it's mobile versions of the app (iOS/Android) aiding that particular business area
How do I map that company with its many business areas onto firebase?
Do I have one project per business area (e.g. selling bananas) containing the three app versions (two mobile, one web) of the specific area and one project that has all the stuff needed for central user management (#3 from above)?
What are my limitations regarding number of projects? If every business area has a staging project for its App then we'll have twice as many projects as we have business areas...
Do I pay per project or per account usage i.e. we would have one account with at least four projects I guess?
Can I have my domains laid out like this
example.com/bananas
example.com/facility-services
example.com/local-transport-and-repair
Thanks a lot for some insight in advance! :)
There's really no direct way to answer this question but Firebase is more than capable of handling this use case within a single project. Doing it that way allows for one user base and if needed, resources can be easily shared between 'departments'
Conceptually, it's pretty straight forward; but we don't have a lot of specific info to go on in the question so here's one example.
Supposed this is a fictuous company that distributes bananas as well as offers banana services for facilities and repairs and maintains banana trucks. We'll call this company; Real Ap-Peel.
real-apPeel
sell_banana_div
//here we store all data about selling bananas
facility_services_div
//here we store the data about facility services
services_repair_div
//here we store service and repair data
users //all users
uid_0:
div:
sell_banana_div: true
uid_1:
div:
facility_services_div: true
uid_2:
div:
sell_banana_div: true
services_repair_div: true
In the above setup for our company, we have three separate divisions with their own subset of data. We also have one unified users node to track the users and a child called 'div' which will determine what division that user belongs to.
The last user, uid_2 belongs to two divisions and can therefore access data in the sell_bananas_div as well as the services_repair_div. Handling accessing data in both divisions is done through code and enforced through Firebase Rules.
If you NEVER need to share ANY data between any of the divisions, then there's no reason to have a combined structure like this so go ahead and split it out into separate apps.
However...
Combining data lets you have one app, one code base and one set of users which makes it considerably more maintainable and expandable.
You asked the following:
Do I have one project per business area (e.g. selling bananas)
containing the three app versions (two mobile, one web) of the
specific area and one project that has all the stuff needed for
central user management (#3 from above)?
All of that is combined into one app, per my above example, and can be any combo or mobile or web.
What are my limitations regarding number of projects? If every
business area has a staging project for its App then we'll have twice
as many projects as we have business areas...
Issue eliminated as it's just one project
Do I pay per project or per account usage i.e. we would have one
account with at least four projects I guess?
This is more of a direct question to Firebase if you choose this path. Contact support#firebase.com
Can I have my domains laid out like this example.com/bananas
example.com/facility-services example.com/local-transport-and-repair
My above example pretty much does that - a single realappeel.com and then the references to the child nodes are realappeel.com/sell_banana_div etc.
I hope this isn't too far off the question. If so, post and comment and I will update (or delete if its waaaaaay off base!)
I need to build a secure web application that allows sports coaches to go in and add points (numerical values) to each of their own sport players.
Each coach should only have access to their own information (through their email and a password) and an area that lets them update only their player's points.
There is a total of 4,000 coaches and 10,000 players that have to allocated to their appropriate coaches.
I have attached an image of how that would work through a crappy hand drawing.
What would be the best web application to develop this on?
Web Map of Coaches and Players relationship
Well, this is highly subjective. The world is your oyster. It sounds like your webapp is essentially a nice UI layer over a database.
Personally, because I work in these a lot, I'd use Yii (PHP) as a backend and set up models to match my tables in a SQL database. I'd create a controller as an API to expose those models to AJAX calls.
In the SQL database itself, I'd set up the coach/player relationships, as well as access rights for the different coach login profiles and admin rights for the admin profiles.
Then I'd set up an AngularJS frontend to display it all. With Angular, and other frameworks, it'd be really easy to rig up a table using filters to make player info searchable and filterable on things like name, score, player number, etc. I'd also want an interface to add coaches, and you'd want to give coaches the ability to add players.
It's so subjective though. You could do a noSQL database, java backend, c++ backend, scala, nodeJS, react.js, etc, etc. There's no one "right" solution. It basically comes down to your own programming preferences.
Seth pretty much summed up the very broadness this question brings for answers, but I actually created something very similar to this in Drupal. This website/app was used to run a multi-day fishing tournament.
The quick and dirty answer here (when using Drupal anyway) would be to restrict access through creatively setting up Roles and Taxonomy Terms for the coaches and players and only allowing Coaches to see players that have a certain term attached to them (when I say Coaches and Players, Coaches could be Drupal 'Users' and Players could be a content type, for example). You could then create another content type (entity) to hold the Points and then attach the Points to each player.
Another solution would be using Organic Groups and making the coaches group admins and putting their players in their own groups... So many different ways to handle this.
The reason I suggested Drupal was because a lot of the grunt work is already done for you. It already has the options to create/manage Users, restrict access to content and set up entities and tie them all together. This could totally be built from the ground up, as Seth suggested or it could be built on a framework or an existing content management system.
Please review the scenario and solution I came up with. If it sucks please tell me so.
Scenario
Need to create an application for submitting & viewing accidents reports that will be used by 50 schools. When submitting a form, an employee will select their school from a dropdown. Likewise when viewing accident reports, the employee will select their school from a dropdown. Some employee's are to be assigned multiple schools. Thus the dropdown needs to be populated with each school they are assigned to. The IT department wants to control the population of the dropdowns using Active Directory.
Possible Solution
Within Active Directory, create an organizational unit called AccidentReportingSchools
Within the organizational unit, create a security group for each school.
Add an attribute called SchoolName to the security group
Add an attribute called SchoolID to the security group
Write an active directory query to return all of the security groups that are within the AccidentReportingSchools organizational unit (created from step 1) that the logged in employee is a member of.
When an employee logs into the application, create a session variable or cookie for storing the employee's schools. Populate it based on the results of the active directory query.
Use the cookie/session variable to populate the dropdowns.
Alternate Solution
Tell the IT department that Active Directory is not well suited in this particular situation and that a database table should be used for assigning employees to their schools.
It doesn't sound like a bad idea. Though I don't think you need to setup an attribute for SchoolName. You can just go by the name of the AD Group. I have something similar (though not nearly as large in scope.) I created a basic Intranet page for IT Trouble Tickets.
And for what it's worth, if you plan on doing this through ASP.net look at MVC rather than WebForms.
My client has a three tier organizational model, with 184 total business units. I imported the business units from file, which created a default team for each business unit. Unfortunately these teams by default have no user roles and cannot be assigned ownership of entities.
My next move was to select all of my teams and do a bulk "Manage Roles" to set all teams to have a user role of Customer Service Rep. This results in a warning that "You have selected users from different business units. Users cannot be assigned roles from business units outside their own, so only the selected roles from each user's business unit will be assigned." In essence, this means that if I bulk edit roles, I will need to select 184 roles, one instance of the Customer Service Rep role for each business unit.
This seems remarkably stupid, since there is in fact only one Customer Service Rep role that to my knowledge behaves identically across all 184 business units. I am looking for insight into why the bulk role editing behaves this way, as well as a solution for assigning all of my business units the desired role.
Thanks!
I am building a subscription based web site, which currently has three subscription levels, i.e. Horses, Soccer, and Horses and Soccer. I was thinking of implementing standard role based authorization, where a Horses subscriber would get roles including those to use the Horses section, etc.
Should I use a standard role provider, and when a member subscribes to the site, assign roles for his subscription to him, or use a hierarchical role provider, that when asked for the roles for a member, only then uses the member's subscription level to 'calculate' a set of roles for the member.
Approach 1 is more controlled and deterministic as opposed to approach 2.
It will depend on how many 'public' areas you have.. If there are manu public areas and roles apply only to chosen few content, I would go with option 2 otherwise option 1.
Seems to be aspnet roles and assing the roles seems like a good solution to me that requires minimal amount of code