RE: Object authority

Michael,

I don't see why adopted authority would require "revoking" permissions
verses "granting " with group profiles.

Whereas many sites using adopted authority use only a single owning profile.
There's no reason why in your situation, multiple profiles couldn't be used
for different parts of the application.

Adopted authority works quite well in an environment were access must be
explicitly granted.

IMHO, it works even better than group profiles because as Rob pointed out,
with group profiles by themselves, you've given users authority to do
whatever they want to objects and programs.

Using adopted authority, the users are simply authorized to use pre-approved
programs.  Those programs in turn have the authority to make changes to the
data.

Charles


> -----Original Message-----
> From: Rooney, Michael P [mailto:michael.p.rooney@xxxxxxxxxxxxx]
> Sent: Tuesday, March 23, 2004 1:32 PM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: Object authority
> 
> 
> 
> While I have no doubt that this approach works in yours (and 
> probably other)
> environments, the gaping hole you speak of may lay in some 
> "unauthorized"
> persons ability to execute one of these programs.  As the 
> program executes
> as *OWNER, OS/400, as you pointed out, doesn't enforce any authorities
> on the objects used by the individual executing the program.  In this
> case, it's not the "inclusion" of users that would concern me but the
> "exclusion" of individuals.  
> 
> What I find more concerning is the use of QPGMR.  As this is 
> an IBM-supplied
> profile, creating all programs to adopt these permissions is 
> more dangerous
> than your approach (i.e. creating a specific profile).
> 
> Working in a highly regulated industry, we are subjected to 
> annual audits
> by the FRB and SEC.  One of the items that is reviewed 
> without hesitation
> is the identification of programs that execute under adopted 
> authority.  This
> review is NOT limited to just QSECOFR.
> 
> Our solution is the use of Group Profiles.  Where as, we 
> create programs and
> files with specific ownerships based upon the application.  
> Individual users
> are than "added" to the group "owning" the objects.  This 
> enables us to have
> users enrolled in 1 group, 2 groups or no groups (i.e. exclusion).
> 
> Now before anyone says you can do the same by "revoking" 
> permissions to the
> qualified objects, we prefer to operate on the "need to use 
> basis", where
> you are granted access based on your need to use.  In other 
> words, we don't
> want to have to "revoke" access to everything we create.  
> With 300+ users,
> this approach works best in our environment while (most 
> importantly) satisfying
> regulators.
> 
> Hope this feedback is helpful.
> 
> MichaelR
> 
> 
>  
> 
> 
> 
> 
>