|
Hi Brian The way we do this is that our menu application stores an authority mask at menu header and menu detail level and checks this against an authority mask stored for each user profile. The mask consists of: Authorisation Level (1 char) Job Authority (1 char) Knowledge Level (1 char) Dept Code (3 char) Application/Module ID (3 char) The first three mask fields hold a value in the range of blank, 1-9 and A-Z with 1 being highest and Z being lowest level. The Dept Code limits menu options to users with the same value or blanks, as does the Application/Module ID. A user with a completely blank mask is allowed access to everything as blanks bypass the checking at that level. It's probably not the best way of doing it, but it works for us and allows users with differing levels of authority to share the same menu without any risk. All the best Jonathan -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Brian Piotrowski Sent: 21 September 2006 15:38 To: Midrange Systems Technical Discussion Subject: User Security Advice Hi All, Does anyone have any advice on protecting home-grown programs and user security? Right now we have a very rudimentary security system that protects programs based on the users "level". This level has nothing to do with the built-in security used by the AS/400. Instead, there's an additional PF that houses the username, a security category (ie: "A" for all programs, "S" for only scanning programs, etc.). and a security level (3 - can do everything, 0 - can do very little). We're looking at revamping our entire security system to make it more granular. Instead of having a broad security level such as "A3", I'm looking to go right down to the menu items and restrict on that. So if we have "001 - Production Control, 002 - Trailer Control, 003 - User Profiles", I would have the user maintenance program allow access to 001, and 003 for a user, but restrict them from using 002. However, we have almost 275 programs spread across 15 menus, so a user's profile may be large because in addition to their name and password, they will have an extra 275 fields that will have a "Y" or "N" in them to restrict their access to the programs. Furthermore, when new menu items are added, I will need to go into the user profile program and update all records. So I'm not sure if this is a viable solution. I thought I'd consult the group for some advice, since I'm sure there are others who have done this before. If not, are there any good Redbooks that cover this issue or has everyone rolled out their own security solutions? Thanks! /b; -=-=-=-=-=-=-=-=-=-=-=-=-=- Brian Piotrowski Assistant Mgr. - I.T. Simcoe Parts Service, Inc. Ph: 705-435-7814 x343 Fx: 705-435-6746 -=-=-=-=-=-=-=-=-=-=-=-=-=- -- 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.