RE: Documenting / Managing iSeries security

Rob,

Ok I can see where you are coming from.  I assume you are using BPCS
security to prevent users from doing stuff they are not authorized to do.
Thus, group profiles might be of little use.  Unless the users that use
single libraries or multiple libraries are fixed.  What I mean is that a
user in a given role (AP for instance) deals with a given set of companies.
If that user were to leave then his/her replacement would deal with the same
set of companies.

For example, say your AP people work across all companies, you could have a
GRPALLCMPYS.  Users that only access one company would be in GRPxxxxxxx
where the xxxxxx is something appropriate.

Finally if you could identify subsets of users that need access to given
subsets of company (say order entry for three companies are handled by the
same set of users) you could have other groups for those sets.  This would
be beneficial even if the subset of users is only one user.

Granted, the group profiles aren't as useful in your case since you've got a
small set of authorization lists being used.  Still I think there'd be
benefits to having the group profiles on the authorization list as opposed
to individual users.  If nothing else, to add a new user you'd simply copy
an existing and the user would have appropriate authority with no extra work
needed.


Charles




> -----Original Message-----
> From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
> Sent: Thursday, May 27, 2004 2:29 PM
> To: Security Administration on the AS400 / iSeries
> Subject: RE: [Security400] Documenting / Managing iSeries security
> 
> 
> Here's where we are coming from:
> http://www.dekko.com/GroupDekko.nsf/Companies
> Each of these companies have their own data library, program 
> library and 
> query library.  For example:
> CLIDIVF, CLIDIVO, CLIDIVQ
> DETDIVF, DETDIVO, DETDIVQ
> MCIDIVF, MCIDIVO, MCIDIVQ
> and so on..
> Each library has their own authorization list.
> Some employees actually do work for more than one company.
> Need further explanation?  I don't want to flood you with 
> information when 
> that might be enough to explain it.
> 
> We actually have so many files that it is impossible for SSA 
> to own all of 
> them.  There is a limit to how many objects one user may own. 
>  Actually 
> that was the straw that got us securing each companies data 
> file library 
> better.