RE: Restricting User Access

["Kahn, David (kahn)" <KAHN@xxxxxxxxxxxxxxxxxx>]

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
=========

kahn@tengizchevroil.com   (to November 25)
dkahn@cix.compulink.co.uk (from November 26)

>-----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
+---