Security Model

Source: app_sec library (user/security maintenance screens), homersys (n_system_menu_security menu filtering), function f_check_group_security, and the security_* tables; official intent from the user guide's security chapter (User Guide ch. 28).

The intended six-level model (User Guide ch. 28)

The user guide's security chapter — the official statement of how HOMER security was meant to work — describes six levels, whose purpose is to "ensure the division of labor, protect sensitive data and aid in tracking down problems and problem users". They map onto the mechanisms found in code:

Level	Official description	Mechanism in code
1	An Oracle user id and password, created by the Oracle DBA from the user's full name and initials. Without it, the user cannot log on.	SEC-1 — login is a DB connection (w_homer_logon)
2	The Homer "user": the administrator names the Oracle id in the Security User Maintenance window. "New User" offers only unassigned Oracle ids; a name is associated with the id.	security_users, app_sec/w_user_maint, w_new_user
3	Role and Class. An Oracle Role grants SELECT, UPDATE, INSERT or DELETE on defined database objects; each department has a defined role, and users may belong to more than one role. The Class defines access to a specific group or set of groups of clients, so that one client's users cannot see another client's data; users should belong to only one class. Both are assigned by drag-and-drop in the same window and committed with Save.	security_users_db_role (SEC-1), security_user_class_user + security_user_group (SEC-3)
4–5	PFC object-level security: every application object can be made visible, hidden, or disabled — at group level (groups are departments at SFPI) and at individual level.	security_apps, security_template, security_info (SEC-4)
6	The client segment: a "way of handling data" that divides update rights to commonly accessed data by client group, so one client cannot update (and corrupt) multi-client shared data.	client-segment preference (system/u_app_preference, default SFPI)

Provisioning rules stated by the guide: new roles can only be created by the Oracle DBA, and new classes can currently only be added by editing the table directly — which explains why app_sec contains no class-maintenance screen.

PFC object security is administered outside HOMER (User Guide ch. 28)

Levels 4–5 are not set inside HOMER: they are administered through the PFC Security application, a pre-compiled utility shipped with PowerBuilder (version 5.0 in production; a 6.0 upgrade was attempted and dropped). Its workflow:

1. Security Scanner — an applet that (driven by the developer's pb.ini) scans all objects of a chosen application into security_template, making them available for permission assignment.
2. Member/Group assignment — assigns individuals to groups (departments). A user must already have a role and a class before appearing in this window. Individuals may belong to more than one group, but the guide recommends against it because rights can overlap.
3. Group/Object permissions — per window, every contained object (edits, menu items, static text, buttons, ...) gets one of four statuses: Not Set (default — security not set at this level), Enabled (full access), Disabled (visible greyed-out, not usable), Invisible (not visible at all).
4. Individual permissions — the same procedure with a member instead of a group; the guide warns this is "NOT RECOMMENDED UNLESS COMPLETELY NECESSARY".

Client segmentation (User Guide ch. 28)

Segmentation controls updates, inserts and deletes of commonly accessed data (the guide's example: two clients share a provider; without segmentation one client's provider update corrupts the other's data). Data may be replicated per segment, but each segment's copy stays correct. Clients can belong to more than one segment. Assignment is done in the "Client Segment User Maintenance" screen (menu path: Application Functions / System / Client Segment User Mapping), whose selection list shows the same groups and individuals as the PFC application; right-click Add creates a mapping row with a dropdown of segments.

Concepts

Table	Role
security_users	Application users (name, description, user_type, priority). Users are Oracle accounts (login is a DB connection; dddw_new_oracle_users picks from all_users). user_type '0' denotes a person, '1' a group (User Guide ch. 28).
security_user_class	Roles ("user classes") with descriptions.
security_user_class_user	User ↔ class membership.
security_user_group	Data-level security: which employer groups a user class may work with.
security_db_role / security_users_db_role	Oracle database roles granted per user.
security_menu_options	Function-level security: per menu entry, a setting for a name that is either a user or a class (name_type), layered app-default → class → user.
system_menu	The navigable function tree: menu caption, window_to_open, parameter, display_order, sys_menu_option.
security_apps, security_template, security_info	Window/control-level security templates (per application, window, control). Officially: security_apps names the applications under security; security_template is the scanned object inventory produced by the PFC Security Scanner; security_info — "the most important of all the tables" — lists every object in the repository and which groups/individuals have access at what level (User Guide ch. 28).
security_groupings	Links individual members to the groups they belong to; at SFPI the groups are departments (User Guide ch. 28). Used for worklists/assignment.

Requirements

• SEC-1 — Users authenticate as individual Oracle database accounts; the application opens its DB connection with the user's credentials (n_cst_sfpiappmanager logon; user maintenance creates Oracle users — app_sec/w_new_user, dddw_new_oracle_users). A replacement must provide individual authenticated identities with per-user audit attribution, though not necessarily via database accounts.
• SEC-2 — Access to functions is role-based: the function tree (system_menu) is filtered per user by layered settings — application default, then user-class setting, then per-user override (n_system_menu_security.of_applymenusecurity, security_menu_options.name_type).
• SEC-3 — Access to data is restricted by employer group: a user may only work with groups mapped to one of their user classes (f_check_group_security: security_user_class_user ⋈ security_user_group on user_class, filtered by USER and group_id).
• SEC-4 — Screen-level restrictions can disable/hide individual windows and controls per application via security templates (security_template, security_info).
• SEC-5 — Security administration screens exist for: user creation (including the underlying account), class membership, class↔group assignment, department groups, supervisor assignment, and security reports (functions by user, users by function, object security) — app_sec/w_user_maint, w_user_assignment, w_user_dept_group, w_user_supervisor_edit, w_sec_report1.
• SEC-6 — A user's class determines which client groups the user can see; the purpose is client confidentiality (one client's users must not see another client's data — the guide's example: a class showing all groups except SFPI so Cleveland-office staff cannot see colleague data, or a single-group class for a group doing its own enrollment). Official policy: a user belongs to exactly one class, while a user may belong to multiple roles. (User Guide ch. 28) See discrepancy note below on multiple classes.
• SEC-7 — Object-level (window/control) permissions use four states — Not Set (default: not decided at this level), Enabled, Disabled (visible greyed-out), Invisible — assigned per group (department) with per-individual overrides allowed but officially discouraged. (User Guide ch. 28; storage: security_info, SEC-4)
• SEC-8 — Object-level security is administered outside the application by the PowerBuilder PFC Security utility (v5.0), whose Security Scanner inventories application objects into security_template. (User Guide ch. 28) A replacement must provide an in-product (or at least supported) equivalent for object-permission administration and for keeping the object inventory in sync with releases.
• SEC-9 — Client segmentation partitions update/insert/delete rights to commonly shared data by client segment, so one client cannot corrupt data other clients use; data may be replicated per segment; clients can belong to more than one segment. Segment membership is maintained in the "Client Segment User Maintenance" screen (Application Functions / System / Client Segment User Mapping). (User Guide ch. 28)

Screens (app_sec library)

Window	Purpose
app_sec/w_maint_security	Main security maintenance — create and maintain user security for the application (function/menu settings per user or class, via d_security_menu_options).
app_sec/w_user_info_maint_selection / app_sec/w_user_info_edit	User profile list and editor (demographics, department, supervisor, location; DataWindows d_user_info_selection, d_user_info_edit).
app_sec/w_user_maint, app_sec/w_new_user	User account creation/maintenance, including the underlying Oracle account and role grants (SEC-1, SEC-5).
app_sec/w_user_assignment / app_sec/w_user_assignment_error	Assign users to classes/groups via wizard; the error window lists conflicting user-group assignments detected during assignment.
app_sec/w_cust_group_sec	Maintain customer-group security — which employer groups a user class may access (security_user_group, SEC-3).
app_sec/w_user_dept_group	Department-group membership maintenance (security_groupings).
app_sec/w_user_supervisor_edit	Supervisor assignment per user.
app_sec/w_sec_report1, app_sec/w_system_menu_security	Security reports (functions by user, users by function, object security) and menu-security review.

Discrepancies (code vs. user guide)

• Menu security table. The user guide (ch. 28) lists a table SECURITY_USER_MENU_OPT and states it "is empty — looks like it is used to define menu access." The code, however, actively implements menu security through security_menu_options layered app-default → class → user (SEC-2, n_system_menu_security.of_applymenusecurity). Menu-level security was evidently built out after the guide was written (1999); code wins for current behavior — discrepancy for SME confirmation (and confirm whether security_user_menu_opt is the same table renamed or a dead ancestor).
• One class per user. The guide (ch. 28) states users should belong to only one class, but the schema and f_check_group_security (join through security_user_class_user) tolerate multiple class memberships. Code wins for behavior (multiple classes union their group visibility); the single-class rule appears to be operating policy, not an enforced constraint — discrepancy for SME confirmation before the replacement decides whether to enforce it.

Open question

The live contents of system_menu, security_user_class, and security_menu_options define the actual production function tree and role matrix. Export them before designing the replacement's role model (OQ-1 in Migration Considerations). The user guide (ch. 28) now documents the intended semantics of roles (per-department Oracle roles) and classes (client visibility), but not the live matrix — the export is still required. Also export security_user_class contents against the guide's examples (e.g. the "all groups except SFPI" class).