RE: Design pattern for row-level security? -- MIDRANGE-L

There's a big sign on the Security Map about what you are asking.  It says 
Beyonde this playce there be Dragons."  

The only solution that comes to my mind that is maintainable by future
legions of maintenance programmers would be to deny all access to the
original data by any method whatsoever.  And then....

Once you are sure the data itself is not reachable then you can write one
set of programs that add, change and deletes rows of the data.

In that application suite of programs you can build your Rulz and do your
processing against various data structures for various purposes, people, and
actions.
 
 
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: Midrange Systems Technical Discussion
Date: Monday, May 05, 2003 08:51:27
To: 'Midrange Systems Technical Discussion'
Subject: RE: Design pattern for row-level security?
 
>Is this a case where program logic is your best solution?
 
Program logic is the only way to do this. But I know I'm not the first
person to implement a security system so I'm looking for a pattern to copy. 
 
I'm thinking about the object-level security in OS/400 as a model. Every
record in the system has a unique GUID so I could have a common security
table, but it's the multiple inheritance and exceptions that are driving me
nuts. 
 
Oh, and it's a ColdFusion/ASP.NET app with a SQLServer back end, no iSeries
involved, but the business problem is technology-agnostic so I figured I'd
give everyone here a shot.
 
-Walden
 
------------
Walden H Leverich III
President
Tech Software
(516) 627-3800 x11
(208) 692-3308 eFax
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 
 
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
 
 
-----Original Message-----
From: PaulMmn [mailto:PaulMmn@xxxxxxxxxxxxx] 
Sent: Saturday, May 03, 2003 1:01 AM
To: Midrange Systems Technical Discussion
Subject: Re: Design pattern for row-level security?
 
 
You may need to think about referntial integrity options as well as
triggers--
 
Also look at some of the abilities of logical files-- you would have 
to do some program changing, but you can create an LF that only 
includes the fields that you want updatable, and maybe access the PF 
as read only... maybe.
 
Is this a case where program logic is your best solution?
 
--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx
 
 
 
 
>Has anyone implemented a system that supports row-level security? By
>row-level I'm speaking of a system where you could say:
>
>Mike can add comments to items.
>Mike can change items.
>Mike can NOT access item 12345 in any way (not even read)
>Jane can display any item where she is the product-line manager
>Jane can not display item 87997 even though she is product-line manager
>Pete can edit items where he is buyer
>Pete can edit item 99890 (even though he isn't buyer)
>Pete can add notes to items where he is seconday buyer, but can't change
>them.
>
>Any experience or places to look for decent design patterns?
>
>-Walden
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
 
.