The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Implementing security on data

Hello everyone
I am currently looking for ways to implement access control on a software data. we already have authorization on features, and would like to handle scenarios such as:
- an employee from one division does not see the work of other divisions.
- a salesperson in one city/region can see/deal only with customers in that region.
- a salesperson can have only readonly access to other salespersons affairs in a same location, and a manager can reassign clients to salespersons.

these are just a few rules among many that we will have to be able to implement. in fact, we need to give our client a full control to set whatever rule might be needed.

the idea is to present on one side the users and groups of users, and on other side the classes of data (customers categories, regions, products/product categories, etc...) then allow the manager to set the access rules.

is there any best practice, guidance or reference on how to implement that ? or what is commonly practiced ?
any pointers will be helpful.

thanks in advance.
RMS Send private email
Tuesday, September 18, 2007
Before going further: Are you sure you want this?

I ask again, Are you absolutely, positively, 100% *SURE* you want this?

I've been involved in 3 distinct projects for 3 different customers that were all 100% positive they wanted this.

We built it. ... ... ... ... They never used it. Evar!

It comes down to a maintenance problem, and that problem is usually a nightmare. You end up with folks spending more time configuring the data on who has access, what kind of access they have and granting/revoking permissions all damned day.

Sooner or later, someone gets the BrightIdea(tm) to grant the magical "ALL" permission to the even more magical "EVERYONE" group -- " 'cause it's just *easier* that way, and we can get our jobs done now!".

Before you go down this road think loooooonnnng and hard about it. They say they want it. They think they want it. Hell, they actually even *want* it, but in my experience they'll never use it. Users are quite fickle that way.

3 times I've done it (and it ain't easy to wedge into an already developed application w/ more than 7 years of constant development and maintenance of legacy code).

3 times the result is the same.

They're not gonna use it.
Wednesday, September 19, 2007
+1 Sgt.Sausage

Make it too simplified, so that even managers can use it, and they will bitch about not having enough possibilities. Make it sophisticated and all combinations possible, and even experienced administrators won't get it right. And even if they do, in the long run there will be a special case here, another there, a quick and undocumented change ordered by the CEO required yesterday, and suddenly things are messed up in a way that it requires a man-month project to get it right again.

It doesn't stop on the salesperson-customer relation. It requires strict rules about which administrator is allowed to make which changes. And someone has to administrate the administrator's rights, of course.

I have yet to see one single Active Directory rights and permissions scheme that was done right and not messed up in the long run.
Wednesday, September 19, 2007
Have a look at Row-Level Security in SQL Server 2005 - it is a bit rubbish, but there is a model which you can follow.

Another option would be to look at the implementation in Analysis Services - if you can use AS to back-end all your reports, it is slightly less messy than the database option.

But overall, I agree with everyone who has said "don't touch it with a bargepole" - you'll get a lot of grief, they'll never get the system they want, and eventually everyone will give up and go home.
Syd Send private email
Wednesday, September 19, 2007
If you have clear and visible auditing of who changed what then many security requirements can often be implemented as business processes rather than using technology.
Arethuza Send private email
Wednesday, September 19, 2007
+ eleventy billion to Sgt. Sausage

Those rights systems are always over-engineered and under-utilized.  It just makes some people feel better to know that others can't do certain things (*cough*governmentmanagement*cough*).

People in Dept. A will not mess with the data from Dept. B, because they have no reason to.  Your system should make distinguishing "my data" from "someone else's data" very easy for the user.  And, as long as you log changes, when someone messes with data they shouldn't it's not a big deal.
John Cromartie Send private email
Wednesday, September 19, 2007
+MAX_INT for Sarge, John and the others.

If you make is sophisticated enough to do any useful separation, it'll be too complicated for all but .001% of your users.  And in two years, when that .001% person has moved on, your program will be "too rigid" because no one will know (or care) how to change the rules to match their then-current business.

The last time I did this, the organisation brought back a retiree at contractor rates to do the rules maintenance.
a former big-fiver Send private email
Wednesday, September 19, 2007
Our app has this all over the place and unfortunately in our place it is absolutely mandatory and everyone uses it. Basically our system is for stock brokers and if broker A ever saw the data from broker B's clients, broker A would steal all the clients just a tad faster than broker B would sue our asses off.

Superficially, this is simple (just have a tag on each account as to which user owns it) but you get into endless complications when people say things like "show me all my trades in Microsoft stock, and include all the guys in my branch because I'm the branch manager, and I want it sorted in some special order, and there are 1 million transactions in total but I only want to see the first 50".

Ugly area. Avoid it if you can. I wish we could.
Greg Send private email
Thursday, September 20, 2007
"+MAX_INT for Sarge, John and the others."

Which in most cases will work out as -1 for Sarge and John. Oh well.
Duncan Sharpe
Friday, September 21, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz