MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » June 2014

RE: Read Only Access Profile



fixed

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



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Chella R
Sent: Tuesday, June 10, 2014 5:07 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Read Only Access Profile

Hi,

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.

Thanks/Best Regards
Chella Govindarajan R,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Disclaimer~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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,
visit: http://lists.midrange.com/mailman/listinfo/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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact