We are using BPCS security. But as anyone knows who doesn't keep their head buried in the sand, the days of relying on 5250 menu based security for data protection are long past. We're not ready for 'application only access'. Very little data gets downloaded, but we do use a lot of queries. You use group profiles to secure by application: A/P, etc. We use group profiles to secure by company. Too much of the applications interface to do it here by application. Although we are using a separate accounting package and that has it's own group profiles, etc. Yes, trying to figure out what authorization lists to put their replacement in when someone leaves is a trick. Often, instead of deleting someone, we'll just disable them. (And, no, that doesn't mean we use Nick the Kneebreaker instead of Mack the Knife.) We could then determine what authorization lists this person is a member of and add the new person likewise. Trying to decide out of the hundreds of BPCS files to put in a particular group would be a real chore. For example, what files will the group GRPALLAP have access to might involve a lot of trial and terror. Although I am beginning to understand what you are saying. Everything in CLIDIVF may be owned by SSA36 but GRPALLAP might have update access to AVM (the vendor master) and a selection of other files. Then when the person doing that job gets replaced then some new person gets added to that group profile. But they would also need the supplemental group of SSA to use the BPCS programs, etc. And as much as I hate supplemental groups that ain't happening. I suppose the programs for BPCS could be *PUBLIC *USE without the earth coming to an end. Unless they do something stupid like one package we used to have. That package had a program owned by QSECOFR that only did a CALL QUSCMDLN. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com CWilt@xxxxxxxxxxxx Sent by: security400-bounces@xxxxxxxxxxxx 05/27/2004 03:03 PM Please respond to Security Administration on the AS400 / iSeries <security400@xxxxxxxxxxxx> To security400@xxxxxxxxxxxx cc Subject RE: [Security400] 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. _______________________________________________ This is the Security Administration on the AS400 / iSeries (Security400) mailing list To post a message email: Security400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/security400 or email: Security400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/security400.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.