No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


eSight V300R010C00SPC200, 300, and 500 Self-Service Integration Guide 10

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).


Basic Concepts

As a part of identity management, SSO allows a user to log in once and gains access to all application systems without being prompted to log in again at each of them.

SSO involves technical terms including ticket granting ticket (TGT), service ticket (ST), and ticket granting cookie (TGC).

SSO roles include the following:

  • Authentication center: provides the authentication service. When a user accesses a web application server address managed by SSO, the SSO server authenticates the user according to user information in the authentication center. The user can log in to the web application system only after passing authentication in the authentication center and access other web application systems managed by SSO without closing all browsers.
  • SSO server: authenticates users and provides the SSO service. The SSO server can process user names and passwords by searching the database for user account information or searching XML files for user passwords. SSO provides a flexible and unified method by separating interfaces from implementation. Details about SSO authentication implementation can be customized and extended. Currently, eSight can serve as an SSO server and authenticate users through the security management service.
  • SSO client: is deployed in the application system (web or C/S structure). When a user requests access to protect resources in an application system, the SSO client transfers the request to the SSO server for authentication and SSO services.
Figure 2-1 SSO system architecture


Web SSO applications communicate through web protocols such as HTTP and SSL, and SSO provides only one login entry. Desktop SSO is another mode. For example, after a user logs in to Windows 2000 as Administrator, the user can use MSN or QQ without login. This is the password entering proxy function but not password remembering function on client software. Therefore, desktop SSO provides the service on the operating system.

In web SSO, the web server and browsers use cookie technology to maintain application status. A cookie is a text-only string that can be set by the web server and stored in the browser. When the browser requests page 1, the web server sets a cookie and returns the cookie and page 1 to the browser. After receiving the cookie, the browser saves it. When the browser requests page 2, the browser brings the cookie. When receiving the request and cookie, the web server determines and restores some information status of the user based on the cookie. Web SSO leverages cookie technology to save user login information and combine the cookie and ticket, implementing the SSO function.


  • Facilitating user operations

    Users can log in to the application system only once but do not need to enter the user name and password at every login to log in for multiple times. The SSO platform improves user experience in using application systems.

  • Facilitating administrator operations

    The administrator only needs to maintain one unified user account, which is easy and convenient. In traditional mode, the administrator must manage many user accounts, each of which maps an application system. These user accounts are not easy to manage and may bring management vulnerabilities.

  • Simplifying application system development

    When developing a new application system, the personnel can use the SSO platform for authentication, simplifying the development process. The SSO platform provides the unified authentication mechanism for SSO. Therefore, application systems do not need to develop the user authentication program.


Central Authentication Service (CAS) is an open-source project initiated by Yale University and is widely applied in University of California, Cambridge University, and Hong Kong University of Science and Technology. The independent, easy-to-use CAS supports the proxy function. According to statistics, CAS is used by eight in every 10 Java projects using open sources to construct web SSO. CAS is the most simple, efficient SSO choice that is secure enough.

  • CAS design objectives
    1. To provide SSO infrastructure for multiple web applications and provide the SSO function for non-web applications with web front-end services.
    2. To simplify the user authentication process.
    3. To integrate user authentication on one web application, simplifying user password management and improving security. Modifying authentication logic does not require code modification in many subsystems.
  • CAS implementation

    CAS is designed as an independent web application. CAS runs on multiple Java Servlets of the HTTPS server. HTTP and HTTPS clients are supported.

    When a web browser logs in to the application server, the application server detects server sessions. If no session matches, the application server redirects the URL to the CAS server and requires the user to log in. After the user logs in successfully, the CAS server records the requested application URL and user session ID. The CAS server plants the TGC cookie value to the web browser. Then the web browser with this TGC cookie can access all application servers managed by SSO without login.

    Figure 2-2 CAS SSO process

    When a web browser requests to log out of the application server, the application server redirects the URL to /cas/logout URL on the CAS server. After accepting the request, the CAS server detects the TGC cookie of the user, clears the session, and finds out the URL requests of all application servers that log in through TGC SSO. All invoking requests include the logoutRequest parameter. All application servers parse this parameter to obtain the session ID. The servers then delete the session based on the session ID, therefore implementing single sign-out function.

    Figure 2-3 CAS single sign-out process
Updated: 2019-10-30

Document ID: EDOC1100044386

Views: 15718

Downloads: 83

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Previous Next