Secondary authentication and authorization

Secondary authentication is the process of double-checking the identity of each user who attempts to view, run, schedule, or otherwise act upon an object that is managed by Crystal Enterprise. Authorization is the process of verifying that the user has been granted sufficient rights to perform the requested action upon the specified object.

When a user attempts to access an object on the system, the web browser sends the request by HTTP to the WCS. Before fulfilling the user's request, the WCS performs a series of security-related steps.

First, the WCS ensures that the user has a valid logon token:

• If there is a valid logon token, the WCS proceeds to its next task.
• If there is no valid logon token, the primary authentication process is repeated.

  For more information about logon tokens, see Logon tokens.

Second, the WCS checks internally for an active WCS session that matches the user's logon token:

• If the corresponding WCS session variable remains in memory, the WCS proceeds to its next task.
• If the WCS session variable has timed out, the user is logged back on with the logon token. The SDK authenticates the user against the appropriate user database, and the APS and the WCS recreate the required session variables. In this case, Crystal Enterprise does not have to prompt the user for credentials, because the encoded logon token contains the required information.

Third, the WCS ensures that the appropriate server component actually processes the user's request:

• If the WCS can process the request itself, it queries the APS database for the rights associated with the object that the user requested.

  For instance, if the user requests a list of reports in a specific folder, the WCS queries the APS database for a list of the reports that the user is authorized to see. The WCS then dynamically lists the reports in an HTML page, and sends the page to the user's browser.

• If a different server component must process the request, the WCS sends the request and the user's logon token to the appropriate server component. That server component then queries the APS database for the rights associated with the object that the user requested.

  For instance, if the user attempts to refresh a report's data, the WCS passes the request along to the Page Server. The Page Server passes the logon token to the APS to ensure that the user is authorized to refresh the report.

  For details about how the APS calculates a user's effective rights to an object, see Calculating a user's effective rights.

This secondary authentication and authorization process begins similarly to initial identification; here, however, the authentication algorithm followed by the WCS maintains system security in the fewest number of steps, thereby providing the most efficient response to the user's initial request.

Note:    If the user does not have the right to perform the requested action, the WCS displays an appropriate message. For details about setting object rights, see Controlling Users' Access to Objects.