Security

The oSecurity object is the security guard of your StudioWorks application. oSecurity is instantiated by the main library Startup_Task task variable secur.

When a user signs in to a StudioWorks application, the wSignIn window sends a $signIn(pUserID,pPassword) message to the oSecurity object. The $signIn method searches for the UserID in the list of users and, if found, verifies the password. If the UserID is found and the password matches; information about the user and their security clearances (window instances and schemas) are loaded into the oSecurity object instance and kTrue is returned to the sender. The sign-in process continues and the main window is opened where the user is presented with the navigation treelist of window instances which they are permitted to access.

Sign-in is the first level of security in StudioWorks. The next levels of security in StudioWorks are:

1. Window Instances - whether or not the user may access a window instance.
2. Schemas - whether or not the user has permission to view, insert, edit, or delete records of a particular schema class.

Any user which is declared to be a system administrator has access to all window instances and has full permissions for all schema classes. You do not need to set security for system administrators.

If have an application which does not require security, or a client who does not require security, you can disable StudioWorks security by setting the $:EnforceSecurity property of the oSecurity object to false.

Do secur.$:EnforceSecurity.$assign(kfalse)

Window Instances Security

Every window instance in a StudioWorks app is declared by the oWindowsList objects. There is one oWindowsList object in each module. The WinInstID must be unique for each window instance.

StudioWorks automatically declares a default list and edit WinInstID for each schema class. For the schema class sAuthor, StudioWorks would declare the WinInstIDs AuthorList and AuthorEdit.

The system administrator has control over which WinInstIDs each user is permitted to access. The navigation treelist only shows WinInstIDs which the user has permission to access.

Schema Security

The system administrator has control over which servertables the user is permitted to access in the database. StudioWorks security uses the schema classes which are mapped to servertables. The security control is broken down into the following permissions for each schema class:

1. View - The user can fetch records and view them.
2. Insert - The user can insert new records.
3. Edit - The user can edit existing records.
4. Delete - The user can delete existing records, provided that there aren't any child records with restricted delete constraints.
5. MultiUpdate - The user can mass update a field of multiple records at the same time. (This is a StudioWorks future enhancement.)

Setting Security Privileges

The system administrator controls security for users and groups.

1. Users - Each user must be added to the database. The Usr table is normally where the user records are stored.
2. Groups - Window instance and schema class privileges can be given to a group. Users can be linked to one or more groups. This makes it easier to administer security for large groups of users.

Window instances and schema class permissions are set by the system administrator in the Security window. In the Security window you can add or remove users from groups, allow or deny access to window instances, and set permissions for schema classes.

Some window instances have a baseschema declared for it in the oWindows list. If access is given to the WinInstID, but view permission is not given to the schema class, a red checkmark will be displayed for the WinInstID access in the Security window.

It is recommended that a Group be set up for each type of task or job function and security privileges be set for the Group, then Users added to the Group. This makes it much simpler to administer security. If a user's position or job function changes they can be added or removed from the applicable groups.

Writing Security Sensitive Code

From the StudioWorks developer's point of view, you normally only need to deal with the public interface of the oSecurity object class. The oSecurity object class is instantiated by the main library Startup_Task task variable, secur.

Messages can be sent to oSecurity as needed in your code.

Do secur.$:UserKey Returns UserKey
Do secur.$:UserFormalName Returns FormalName

If secur.$canDelete(BaseSchema)
   ; Display the 'Delete' button in the toolbar
   ; or delete the selected records.
End If

Special Security Groups

You can create groups for purposes other than window instance or schema security. You may need to create a special group for users which are authorized to click an Accept Order button on a particular window.

You could create an AcceptNewSalesOrders group and add users to this group in the Security window. When the window instance is opened you could enable/disable the Accept Order pushbutton based on whether or not the current user is a member of the AcceptNewSalesOrders group.

; Enable/disable the 'Accept Order' button based on whether or
; not the user is a member of the 'AcceptNewSalesOrders' security group.
Do secur.$isMemberOfGroup('AcceptNewSalesOrders') Returns bAuthorized
Do irAcceptOrdersButton.$enabled.$assign(bAuthorized)

Testing User Security

There is a Change User... button on the wSecurity window which prompts you with a list of users. You select a user and continue. The changeUser method then automatically signs you in using the selected user's ID and password. The menus and window are reinstalled so that you can see exactly what windows the user can access and what menus and toolbar buttons are available to the user.

Schema Security Technical Details

The sSchemaSecurity_listdef defines the schema security list used to keep track of the user and group permissions for all of the schema classes. A series of boolean columns, (canview, canedit, caninsert, candelete, canmultiupdate) indicate the specific permissions.

The schema permissions are normally set for a group. When a user is a member of a group, the user inherits the group's permissions. The user's permission is null if they are inheriting the group's permissions. It is possible to override the group permissions for a specific user (though not recommended).

A user could be given different permissions for the same schema class in different groups which the user is a member of. When this happens the user is given the highest permissions for that schema of the groups which it is a member of. This makes for some pretty complicated code in the oSecurity object. StudioWorks has to loop through all of the groups which the user is a member of, then loop through the schema classes and check the permissions and set each permission to the highest level given for the user.

The list and edit window instances decide which toolbar buttons to display based on the user's permissions for the baseschema of the SQL class being used for the window instance.

StudioWorks Documentation - Copyright 2005 Vencor Software