RE: Restricting User Access

RE:     RE: Restricting User Access

>Dave said;  John
>Seems pretty good to me. I like the idea of the keyless logicals, I like
>the idea of adopting the required authority, and I like the "data
>warehouse" library concept. As you are adopting authority at the last
>minute, by doing it in each program rather than in a global initial
>program, you have a number of different authority options to choose from
>depending on the requirements of that program. Are you grading the
>authority adopted or have you gone for a flat system owner scheme?

>Adopting authority as late as possible also protects you from the user
>who discovers an obscure way to break out of the menu system (even a
>wonderful one like ETIKIT)  and start executing commands.

>Are you also providing automated routines to keep an eye on what
>programs adopt what authority? It's not very difficult, but I'd suggest
>you probably need at least to think about this as you will have a large
>number of programs to keep under control, and a little trap door slipped
>into the system might be able to hide quite well.
>Lastly, I wish J.D. Edwards would take a similar approach!
>Dave Kahn, TCO, Kazakstan
=========================================================

Dave;

We have a few major owners,  One for our home grown stuff, and a major one
for each 3rd party package software.

Each individual program is "owned" by one of these.  Each individual program
adopts.   They do not promote their adoption to lower programs.  
So each program has to run on "Its own merits"   This way we can have a 
few odd ball progams owned by a *SECOFR level or whoever is required to do 
a  particluar function.   (like WRKNETF *ALL to an outfile, etc. one of our
traffic logging program utilities.)

I thought the Logical(no keys) over the production Physicals was a neat
Idea myself.  I was very happy that queries still found and could use 
the real indexes over the production PF's.  
It allows us to put into the "Data Warehouse" only those Files/Fields 
we want them to see.  We can lock down this even more granualarness by 
puting security on individual logicals. 

We only have 3 or 4 long term programmers, so our exposure is low from 
that aspect.  No Command lines.  All system interfaces (WRKSPLF, WRKOUTQ
WRKWTR, etc.) are provided by that WONDERFUL menu system in which we can
control which users can see what, start what, stop what, etc.  (very nice)

It seems to lock down the PC desktop and other entrances. 

Is there any other problems we haven't thought of ???

John Carr
EdgeTech    
Consulting / Software / Inhouse Training Classes / User Group Speaker

====================================================================

>-----Original Message-----
>From:  John Carr [SMTP:74711.77@compuserve.com]
>Sent:  Friday, 21 November, 1997 09:19
>To:    Midrange-L
>Subject:       Re: Restricting User Access
>
>
>
>RE:    Re: Restricting User Access
>
>
>
The question about how to keep any user from getting at *PUBLIC authority
>
cuts right to the heart of the Client Access world. 
><snip>
>
>
>Let me pass by you folks our tentitive plans at a client of mine
>and see what problems you think we might have.
>
>Background.
>
>AS/400,  Users all have PC's attached.   Running Win3.1   On the edge of 
>getting into Win95. We have been encourageing users to use Query/400 and
>File Transfer.(It is THEIR data)
>
>All programs Adopt authority.  Single User ID owns all production files 
>& programs.   We have a "Query" library which the users put their 
>Queries & their Outfiles(from queries)into. 
>
>We don't have any *PUBLIC rights over production data.
>
>Users have DATA READ rights, but No OBJECT Rights to production data.
>(in essence users can read the file but can't open it, (Don't seem to make
>sense yet does it.))  
>
>We have a "User Data Warehouse Library"  which contains only logicals 
>OVER only those production files that the users are authorizied 
>to query(Read).
>
>These Logical files do not have any Key Fields(Yes you can do that, 
>like a SQL View. So no Access Path Maintenance overhead.  Also, in certain
>files we only include certain fields in the logical view). 
>
>Users have Just, DATA READ  and OBJECT OPR rights to these logicals.
>(they can READ the files & Open them)
>
>Now,  Users can query(and file transfer) via those logicals to get
>to the production data.  
>
>If you try to access the base physical files in the production libraries
>(or logicals in the "Productional libraries),  You're not authorized.
>
>You can't do file transfer (or anything else, ODBC, FTP, XYZ) against
>the production data because "you're not authorized"
>
>The queries still run great.  If the user sorts the query,  the query
>optimizer still uses/finds existing indexes(the real production logicals 
>which have keys) even though they're not authorized to the "production
>logicals"
>
>This seems to lock down the PC access to the data.  Our production
>programs use menus to "steer" the users to only those progams they 
>can run.  
>
>Sorry for being so long winded to explain the scenerio,  But we think
>it's a good approach.
>
>Until of course you folks start to poke holes in it.
>
>SO
>       production library      user library
>
>       Physical & Logicals     Logicals(no keys)
>       DATA READ rights        DATA READ rights
>       No OBJECT rights        OBJECT OPR rights
>       No *PUBLIC              No *PUBLIC
>
>
>What do you think?
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---