Security Management Guide (G06.24+, H06.03+)

Concerns for the Application Programmer
Security Management Guide—522283-008
6-5
Application-Specific User IDs
Using the Name Database to Authenticate a User
At the beginning of your application, include algorithms to authenticate the user. For
example, you might display a query screen that asks for the user’s name (as known to
the application) and then a password. Ensure that the only way to reach any other
portion of the program is to successfully complete this screen.
If you have many applications that either share the same user-name database or
similar user-name databases, develop and test a standard logon screen. The
advantages of a standard logon screen:
•
You do not have to start over every time you add an application.
•
Your user community quickly becomes accustomed to a standard way to log on to
the applications.
Using the Name Database to Authorize a User’s Actions
After your application has authenticated the user, your application might need to
restrict the actions of the user based on the user’s identity.
You can restrict actions by providing categories of users, similar to the Guardian super
group’s (255,*) inherent authorizations.
Or you can have your application’s name database contain information for each user
about the operations that the user can perform. For example, if your application has 10
screens, you might include a 10-character string in your name database made up of
the characters W, R, and N, meaning Write (and read), Read, and None, respectively.
Each character represents the level of access allowed to the corresponding screen.
For each screen selected by the user, the application program consults the
corresponding position in the string to determine the level of access allowed. You also
need to provide maintenance operations to update these authorization strings.