content
SSO Introduction SSO Theory Basis WebSphere SsoldAP Database Introduction Reference Author Information
Xiao Jing (jing.xiao@chinacreator.com) Software Engineer 2003 August 2003
SSO (SINGLE SIGN-ON) is translated into a login, and SSO mechanism is an identity authentication when entering a corporate network user, and then seamlessly access all authorized network resources. SSO can improve network users. The work efficiency reduces the chance of system error, but it is more difficult to implement. The authors of this paper explain the basic principles of SSO and the SSO implementation mechanism in WebSphere.
1 SSO Introduction SSO (SINGLE SIGN-ON) is translated into a login, and more image in WebSphere is "single sign-on, all net roaming", meaning that all machines that have ended the same DNS domain, you can share users' certification Information, such as: a.chinacreator.com, B.chinacreator.com can implement SSO. SSO mechanism is an identity authentication when entering a corporate network user, then you can subsequently authorized network resources. Perform seamless access, without having to enter your own authentication information multiple times. SSO can improve the work efficiency of network users, reduce the cost of network operation, and improve the security of the network, and reduce the chance of system error, but it is difficult to implement. 1.1 Previous User Logging Mode In order to realize the company's information, e-commerce and other needs, more and more information systems have emerged online, and the network users and system administrators of these companies have to face this reality: 1. Users need When any of the enterprise applications are used, you need to do an identity authentication, and each certified authentication information (user civilian and password) cannot be guaranteed; 2. System administrators need to set a separate security for each system Strategy, and you need to authorize users in each system to ensure that they cannot access network resources they are not authorized to access.
Figure 1: Schematic of multi-point login currently used
1.2 SSO login mode previously used login systems, you need to give a system on each machine, even each app on each machine, ready for user management system and system user authorization policies, considering interoperability Sexuality and security issues, SSO will be together in all domains in an enterprise, and the benefits of SSO are obvious: 1. Reduce the time of logging in to users in different systems, reduce the possibility of user login error 2 To achieve safety while avoiding processing and saving multiple sets of system user authentication information 3. Reduce system administrators to increase, delete users, and modify user rights 4. Increase security: system administrator has a better way Manage users, including access to all system resources access to all system resources by directly disabling and deleting users
Figure 2: Schematic diagram of SSO
2 SSO Theory Basics SSO is not a standard implementation in J2EE, but various middleware providers provide a mechanism for authentication information provided by the J2EE application server cluster, so the implementation methods provided by various manufacturers are different. IBM WebSphere is a Cookies record authentication information, and the BEA's WebLogic achieves sharing of authentication information through session sharing technology. Domestic Shenzhen Kingdee's APUSIC is basically consistent with the BEA technology. But regardless of the implementation of each home, their theoretical foundation is in J2EE: Java Authorization Contract for Containers (Java ACC) and Javatm Authentication and Authorization Service (JaaS). Java Authorization Contract for Containers (Java ACC) and JavatM Authentication and Authorization Service (JAAS) are specifications and criteria for implementing security access mechanisms in J2EE technology, where Java ACC belongs to a part of J2EE specification, while Jaas is the implementation of Java ACC. 2.1 The Java ACC Java ACC specification defines the implementation specification between the authorization policy module and the J2EE container, so that the container security provider can provide the authorization function of the J2EE container according to the requirements of the operating environment. The Java ACC specification is divided into three parts, namely: provide configuration specifications, security policy configuration specifications, policy judgments, and execution specifications. These three parts combine together to describe the installation and configuration of the authorization provider, and the J2EE container user can implement access control based on these specifications. 1. The security provider configuration specification specifies the requirements for security providers and containers, which are the basis of integration between security policy providers and containers. 2. The security policy configuration specification defines the interaction specification between the container configuration tool and the security provider, so-called interaction refers to the process of transforming the declared authorization policy information into the J2SE policy provider to identify instructions. 3. Policy judgment and execution specification define interactions between container policy execution points and security providers, and he implements the security policy judgment required by the J2EE container. Everyone can download the specification documentation in http://java.sun.com/j2ee/javaacc/. 2.2 JaaS Jaas Full name is a Java authentication and authorization service, which is a set of Java packages to provide support based on user-based authentication and access control, which is a standard Embedded Authentication Model (PAM) Java version implementation, support based on users Identity authentication. JaaS is an optional package in J2SE 1.3, but JaaS has been integrated in J2SE1.4. You can view http://java.sun.com/security/jaas/ Doc / Pam.html, JSSA specification can be viewed at http://java.sun.com/products/jaas/. 3 SSO SSO in WebSphere SSO SSO is fully reflected in IBM's products, including in the WebSphere cluster, can be implemented in WebSphere and Domino integration. SSO allows network users to authenticate one of the WebSphere application servers in multiple applications in multiple WebSphere fields, including HTML pages, JSP files, servlets, and corporate EJBs. You can also access documents in other Domino without having to log in to multiple WebSphere domains.
SSO is not supported by default in WebSphere, if you need to implement SSO, you need to configure each WebSphere server. If you need to implement SSO between WebSphere and Domino, you need to reconfigure WebSphere and Domino. 3.2 Prerequisites To implement SSO between WebSphere servers, the following premise: 1. All servers must be configured to be part of the same DNS domain. For example, the DNS domain is configured as Mydomain.com, then SSO will work on all Domino and WebSphere servers, as long as he is on a host belonging to this DNS domain, such as A.Mydomain.com and B.Mydomain.com Between the two Webpshere servers configured on the host. 2. All servers must share the user registry, the user registry can be an LDAP database, and the SSO implementation between the WebSphere server can also use the user's own registry, but Domino does not support the user's own registry that the user is implemented, so WebSphere The LDAP database can only be used as the public user registry when implementing SSO between Domino. [Note] The LDAP database used must be the LDAP database supported by WebSphere. It is recommended to use IBM Security Way. 3. All users are defined in a single LDAP directory. 4. User's browser must support cookies, because the information generated by the server will be passed to the client via cookies, and then submitted to the user access to other servers for authentication. 5. WebSphere should be 3.5 or above. 3.3 The SSO authorization mechanism in WebSphere is relatively simple, using the mechanism of permission management similar to the Windows file, is to define some roles first, then give these roles to access some server resources, then map these roles To a specific user or user group. For example, we developed a web application on a WebSphere server. The administrators of this app can use the management permissions of this web application, and the files related to the administrative authority are placed in this / admin directory, then we can give this Application adds an Admin role that can access all files in the / admin directory, then map this admin role to a group in the LDAP database where all administrator characters is located, as shown in the figure:
