Re: User Security Advice

["Peter Levy" <plevy@xxxxxxxxxxxx>]

> 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.

If I understand this paragraph correctly you're saying you want to:

A) Store passwords in a file, and
B) That this same file will 275 Y/N fields, one for each menu option in your 
application.

As to item "A" I'd use validation list (*VLDL) object where the passwords 
are automatically encrypted. For a secure system a user's password should 
never stored out in the open. There are quite a few APIs one can use to 
maintain the list object and validate passwords that users enter.

As to item "B" that proposal violates one of the basic rules of database 
design: Storing sets of data in one record. If I were designing this 
security application I'd have a file keyed by UserID, MenuName, and Option# 
and have one record for each option. If the record doesn't exist then the 
user wouldn't be authorized to the application. As an added feature, if the 
record exists you could check an authorization code to see what they're 
allowed to do in the program (change or just display).

HTH

Peter Levy
Alliance Shippers IT Department
Englewood Cliffs, NJ
Voice: 201-227-0400 x154
Fax: 201-227-0925
Email: plevy@xxxxxxxxxxxx
AIM ID: pklevyalliance2

-------------------------------------------
There are 10 kinds of people; those who understand binary, and those who 
don't.

----- Original Message ----- 
From: Brian Piotrowski
To: Midrange Systems Technical Discussion
Sent: Thursday, September 21, 2006 10:37 AM
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

-=-=-=-=-=-=-=-=-=-=-=-=-=-