Frequently Asked Questions about Caché Security

The Management Portal consists of several separate web applications. The main page of the Portal is associated with the /csp/sys application and other pages are associated with various /csp/sys/* applications (such as the security-related content, which is associated with the /csp/sys/sec application). If the applications do not all have a common set of authentication mechanism(s) in use, users going from one Portal page to another may encounter login prompts or sudden shifts in their level of privilege.

For example, if the /csp/sys application is using password authentication exclusively, while other related Portal applications are using unauthenticated access exclusively, then, as users move from one Portal page to another, they go from unauthenticated access to requiring authentication. Another possible case is this: the /csp/sys application supports only password authentication, the other applications support only unauthenticated access, and UnknownUser has no special privileges; in this case, when users go from the Portal’s main page to its other pages, they may not have sufficient privileges to perform any action.

To check and configure the authentication mechanism for a web application, select the application from the Web Applications page in the Portal (System Administration > Security > Applications > Web Applications) and, for the displayed application, make selections under Allowed Authentication Methods as appropriate (typically, so that /csp/sys and /csp/sys/* share a common set of authentication mechanisms).

Yes. Security in Caché is always enabled. However, you can configure an instance’s security to mimic the openness of an older system and to support legacy systems without any visible effects.

The following items require attention when upgrading:

• All users require new passwords assigned to them after an upgrade installation.

  The password hash function used is more robust than those used in earlier versions of Caché. Since Caché only stored (and stores) the hashed form of the password for comparison, there is no way to invert the hashed form (giving a plaintext password) and replace it with the hashed value using the newer function. As a result, to take advantage of this robustness, users need to enter new passwords.

• By default, developers do not have privileges on many of the Caché services they did under prior versions.

  The default installation of Caché is configured with a relatively limited set of features accessible by default. The predefined roles do not include privileges for legacy resources such as COM ports, which most customers do not need. As necessary, administrators can alter the predefined roles or create new roles that provide a different set of privileges to meet the needs of each site.

An instance of Caché 5.1 or later operates slightly differently from prior versions of Caché. Differences include:

• As of Caché 5.1, ObjectScript has two system variables, $USERNAME and $ROLES that help applications manage their security needs. Both these variables can be used programmatically in routines, methods, and SQL statements.

• For CSP and Zen applications, security information is maintained as part of the CSP session. The values of $USERNAME and $ROLES are preserved across page requests, even if different processes are used to execute those requests. More specifically, when processing begins for a CSP page, $ROLES contains the user’s roles as well as roles defined for the application.

  The session does not contain roles that were dynamically added during processing of a previous page by setting the value of $ROLES or invoking $SYSTEM.Security.AddRoles. This is true for both stateless sessions and those that maintain state.