RE: Design pattern for row-level security?

Booth,

I gotta push the trigger method versus the maintenance program mentality. 
With the maintenance program mentality any access to Query or any other 
such tool will be allow access to data they shouldn't be looking at. 
Granted, you could lock down all files so that only adopted authority has 
access.  However, if you do the trigger right, even the bloke with *ALLOBJ 
will be locked out of certain rows.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




"Booth Martin" <Booth@xxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/05/2003 03:50 PM
Please respond to Midrange Systems Technical Discussion
 
        To:     <midrange-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        RE: Design pattern for row-level security?


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.

 

. _______________________________________________
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.