Primary authentication

Primary authentication occurs when a user first attempts to access the system. The user provides a user name and password and specifies an authentication type. The authentication type may be Enterprise, Windows NT, or LDAP authentication, depending upon which type(s) you have enabled and set up in the Authorization management area of the Crystal Management Console (CMC). The user's web browser sends the information by HTTP to your web server, which routes the information through the Web Connector to the Web Component Server (WCS).

Note:    All communication between the user's web browser and the WCS is similarly routed through the web server and the Web Connector. For clarity, the web server and the Web Connector are explicitly discussed only when necessary.

The WCS passes the user's information to logon.csp and runs the script. Internally, this script communicates with the SDK and, ultimately, the appropriate security plug-in authenticates the user against the user database.

For instance, if the user specifies Enterprise Authentication, the SDK ensures that the Crystal Enterprise security plug-in performs the authentication. The plug-in component verifies the user name and password against the system database and notifies the Automated Process Scheduler (APS) of the results. Alternatively, if the user specifies Windows NT or LDAP Authentication, the SDK uses the corresponding security plug-in to authenticate the user. The plug-in verifies the user name and password against the external user database and notifies the APS of the results.

If the security plug-in reports a successful match of credentials, the APS grants the user an active identity on the system and the system performs several actions:

• The APS stores the user's information in memory in an APS session variable. While active, this session consumes one user license on the system.
• The APS generates and encodes a logon token and sends it to the WCS.
• The WCS stores the user's information in memory in a WCS session variable. While active, this session stores information that allows Crystal Enterprise to respond to the user's requests.

  Note:    If you are familiar with the SDK, you should note that the WCS here instantiates the InfoStore object and stores it in the WCS session variable.

• The WCS sends the logon token to the user's web browser, and the web browser caches the token in a cookie. Until the logon token expires, its encoded information serves as the user's valid ticket for the system.

Each of these steps contributes to the distributed security of Crystal Enterprise, because each step consists of storing information that is used for secondary identification and authorization purposes. This is the model used in ePortfolio. However, if you are developing your own client application and you prefer not to store session state on the WCS, you can design your application such that it avoids using WCS session variables.

Note:    

• The third-party Windows NT and LDAP security plug-ins work only once you have mapped users and groups from the external user database to Crystal Enterprise. For details, see Available authentication types.
• In a Single Sign On situation, users' credentials are retrieved by other means and authenticated against the user database automatically. Hence, users are not prompted for their credentials.