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, LDAP, or Windows AD 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.
• In a UNIX installation of Crystal Enterprise (or in a Windows installation that uses the Crystal Enterprise Java SDK), there is no Web Connector, and no Web Component Server. All communication between the user's web browser and the rest of Crystal Enterprise is handled by the Java application server and Crystal Enterprise Java SDK.

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 to authenticate 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 Crystal Management Server (CMS) uses the Crystal Enterprise security plug-in component to verify the user name and password against the system database. Alternatively, if the user specifies Windows NT, LDAP, or Windows AD Authentication, the SDK uses the corresponding security plug-in to authenticate the user.

If the security plug-in reports a successful match of credentials (including a match to an appropriate group membership for Windows NT, Windows AD, or LDAP authentication), the CMS grants the user an active identity on the system and the system performs several actions:

• The CMS stores the user's information in memory in a CMS session variable. While active, this session consumes one user license on the system.
• The CMS 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 session variable does not contain the user's password.
• 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 the Crystal Enterprise web desktop. 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, LDAP, and Windows AD security plug-ins work only once you have mapped groups from the external user database to Crystal Enterprise. For details, see Available authentication types.
• In a Single Sign On situation, Crystal Enterprise retrieves users' credentials and group information directly from the Windows NT or Windows AD system. Hence, users are not prompted for their credentials.