You are entering the realm of object level security. A fun and exciting place to be.
One way to restrict a user profile to read is to allow data access through programs only. This is not dissimilar from the n-tier server concept. Users are authorized to execute programs and program owners are authorized to access tables/files/data areas/etc.
Utilizing group profiles is a method for "grouping" users by function. In the above scenario one group can access programs another can access data. You also automatically restrict someone from using network access, such as SQL or FTP, from obtaining or changing your data.
As Rob stated authorization lists make assigning authorizations easier. Secure your programs with authorization lists and secure your data objects with authorization lists.
What I said may make security sound simplistic. It is once you have everything worked out. Working it out takes thought and effort.
If you need on-site assistance with your analysis beyond what this group can supply contact Carol Woodbury at www.skyviewpartners.com or Dan Riehl at www.securemyi.com
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Chella R
Sent: Tuesday, June 10, 2014 5:07 AM
Subject: Read Only Access Profile
I have a requirement to create read-only profile. So the expectation is the profile which would be created, should not be able to write/update/delete records from files in any library of the application. They should only be able to read the records. Can you please suggest how this could be achieved? I have tried few options like RVKOBJAUT command, but I can't use this on all the objects of all the libraries.
Chella Govindarajan R,
Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin@xxxxxxxxx <mailto:mailadmin@xxxxxxxxx>. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of
software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com <http://www.igate.com
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l