Read-Only iSeries User

Bill Dotson

Reputable Poster
Does anyone know how to create a read-only user on the iSeries? We would like to give a couple of folks access to our system, but we want their access to be extremely limited -- read-only for most everything.

Any help from one of you iSeries gurus lurking in the shadows will be greatly appreciated.
 
Hi Bill,

You mention read-only for almost everything...is there a task or something else that it will be ok for this user to do?

Regards,

tarkan
 
Yes, I probably could have been more specific.

We'd like to restrict the user to read-only for specific libraries, in general all of the JDE libraries (CRPDTA, for example, plus DD7333, OL7333, etc.). They can have generic (public?) access everywhere else.

Basically, I want the user to be able to look but not modify. This is a tiny step up from the user's current permissions, which is no access at all (because I haven't even created a profile for the user).
 
There are two levels of security to think about: AS/400 and JDEdwards. In order to ensure that a user is REad-only, you would want to setup AS/400 resource security, securing the JDE objects to *EXCLUDE the *PUBLIC and grant back access to other groups. You can read up on this in the Security Tips and Techniques book that is sent with your operating system. This is not a small project.

The easier and Oracle supported method is to setup this security using JDEdwards applications. Depending on how much security you already have setup, this may or may not be as large a project.
 
Thanks, Jean.

This is purely from the AS400 side, has nothing really to do with JDE (other than that's the data we want to protect). The user's access through JDE is already adequately restricted.

This particular user needs to run some SQL statements against JDE data, but we want the user restricted to using SELECT statements (with UPDATE, INSERT or DELETE prohibited). What I'm really looking for is how to create an AS/400 user profile for this individual, and have that AS/400 profile restricted to read-only access for the JDE libraries.

I can probably find this on the Interweb somewhere, if I sift through enough chaff to find the wheat. Or, I might go blind if I stumble across too many IBM pages.
 
I don't know of a way to secure SQL that way on the AS/400, without securing the database.

You might want to look into 3rd party tools such as Showcase that allow queries against the db, but do not include data update tools.
 
Bill -

I can only assume that you will eventually have other users that need the same ability, so I'll present a somewhat generic solution. Please note that JDE is the name of the iSeries profile that should own and has all authority to the JDE libraries.

Here is one proposed solution for read-only access:

1) Create an iSeries user named <font color="red">READONLY</font> (for example).

2) With the CRTUSRPRF or CHGUSRPRF command, specify the user profile <font color="red">READONLY</font> as the primary group profile (GRPPRF) or one of the supplemental group profiles (SUPGRPPRF) for your "read only" user that needs read-only access to the JDE files.

The rest of this solution depends on how you currently secure your JDE libraries. Some shops use Authorization Lists to define security, others use group profiles and/or private authorities.

(Out of the box, as far as I know Oracle/Peoplesoft uses the latter method.)

2) a) If you use Authorization lists to secure your libraries (I recommend this technique since it is easier to manage), then put <font color="red">READONLY</font> in the authorization list used to secure the library objects, giving it *USE authority. Assuming that you have an authorization list named JDELIBS that is used to secure your JDE libraries,

ADDAUTLE AUTL(JDELIBS) USER( <font color="red">READONLY</font>) AUT(*USE)

Otherwise, for each library that you want to restrict to read only authority for this user:

GRTOBJAUT OBJ(QSYS/YOURJDELIB) OBJTYPE(*LIB) USER( <font color="red">READONLY</font>) AUT(*USE)

Even if this user is a member of the JDE group profile, this should prevent him from updating any files in any of the libraries secured in this fashion.

To test this:
1) Use CRTDUPOBJ to duplicate one of the JDE libraries and create a new library named JDEROTEST.

2) Use CRTDUPOBJ to duplicate several of the JDE physical files (including data) into the JDEROTEST library.

3) Secure JDEROTEST as specified above.

4) Turn your user loose and let him attempt to update or delete the data in the files in JDEROTEST.

Regards,
 
Bill - one additional thing. When testing my solution, create a new user profile for this person to use for read-only access. Don't make these changes to any existing JDE production profiles on the iSeries - it will probably cause errors when they attempt to update files, because of the *USE authority to the libraries.

He/she will need to use the new read-only user profile when performing SQL queries.

Regards,
 
Steve,

Thank you! That's exactly what I was looking for.

This was never intended to replace an existing profile, since this user currently doesn't have 5250 access to the system, so it won't interfere with our JDE profiles. Plus I can test this on our test LPAR first.
 
Hello Steve,
I hope you are doing well.
After almost a decade, I found your very valuable post. I used to work with IBM for more than 20 years (38/AS-400)
NowI am involved in projects about system decommissioning and before save the information, it needs to be accessed on 'read-only' mode only
Thank you again for your help
Jose Gala
 
Back
Top