Single Sign-On (Single Sign-On: Single Sign-On, full-network roaming) Implementation in WebSphere -- technical preparation for SSO implementation

Content SSO Introduction SSO Theory SSO in WebSphere LDAP database Overview References Author Information Xiao Jing (jing.xiao@chinacreator.com) Software Engineer August 2003 SSO (Single Sign-On) is a login. The SSO mechanism is to perform identity authentication when enterprise network users access the enterprise website, then, seamless access can be made to all authorized network resources. SSO can improve the efficiency of network users and reduce the chance of system errors, but it is difficult to implement. The authors in this article explain in detail the basic principles of SSO and the SSO implementation mechanism in WebSphere. 1 SSO Introduction SSO (Single Sign-On) is a Single login. in WebSphere, a more vivid explanation is "Single Sign-On, full-network roaming", which means all machines with the same DNS domain name ending, user authentication information can be shared, such as a.chinacreator.com and B .chinacreator.com. The SSO mechanism is to perform an identity authentication when enterprise network users access the enterprise website. Then, they can seamlessly access all authorized network resources, you do not need to enter your authentication information multiple times. SSO can improve the efficiency of network users, reduce the cost of network operations, improve network security, and reduce the probability of system errors, but it is more difficult to achieve. 1.1 previous user logon Modes In order to meet enterprises' information, e-commerce and other needs, more and more information systems are emerging online. The network users and system administrators of these enterprises have to face this reality: 1. the user needs to perform an identity authentication when using any of the enterprise applications, and the authentication information used for each authentication (user and password) cannot be consistent; 2. the system administrator needs to set a separate security policy for each system and authorize users in each system separately to prevent them from accessing the network resources they are not authorized to access. Figure 1: currently used multi-point Login 1.2 SSO logon Mode In the previous login system, you need to prepare a user management system and system user authorization policy for the system on each machine, or even for each application on each machine, considering the operability and security issues of interoperability, SSO integrates user logon and user account management in all internal domains of an enterprise. The benefits of SSO are obvious: 1. Reduce the time required for users to log on to different systems, and reduce the possibility of user logon errors 2. Security while avoiding the need to process and store authentication information for multiple system users 3. reduced the time required for system administrators to add, delete, and modify user permissions. 4. added security: the system administrator has a better way to manage users, including canceling the user's access permissions to all system resources by directly forbidding or deleting users. Figure 2: SSO Authentication 2. Theoretical Basis of SSO SSO is not a standard implementation in J2EE, but a mechanism provided by various middleware providers to share authentication information when providing J2EE Application Server clusters. Therefore, different vendors provide different implementation methods, IBM WebSphere records authentication information through cookies. BEA's WebLogic shares authentication information through session sharing technology. apusic of Kingdee in Shenzhen adopts the same technology as BEA. However, regardless of the implementation technology, their theoretical basis is due to the security technology 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 the specifications and standards for implementing secure access mechanism in j2ee technology. Java ACC is part of the j2ee specification, JAAS is the implementation part of Java ACC. Java ACC 2.1 The 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 consists of three parts: configuration specification, Security Policy Configuration specification, policy judgment and execution specification. These three parts are combined to describe the installation and configuration of the authorization provider. J2EE container users can implement access control according to these specifications. 1. The security provider configuration specification specifies the requirements for security providers and containers. These are the basis for 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, the so-called interaction refers to the process of converting declared authorization policy information into instructions that can be recognized by J2SE policy providers. 3. Policy judgment and execution specification define the interaction between the container policy execution point and the security provider, and implement the Security Policy judgment required by the J2EE container. You can download the document at http://java.sun.com/j2ee/javaacc. 2.2 JAAS The full name of JAAS is JAVA authentication and authorization service. It is a set of java packages that provide support for user-based authentication and access control. It is a standard embedded authentication model (PAM) java version, supports user identity authentication. JAAS is an optional package in j2se1.3, but JAAS has been integrated in j2se1.4. For details about the standard embedded authentication model (PAM), refer. 3. SSO in WebSphere 3.1 SSO in WebSphere SSO is fully embodied in IBM products, including in WebSphere clusters and integration between WebSphere and Domino. SSO allows network users to authenticate a WebSphere Application Server to access various resources in other WebSphere domains, including HTML pages, JSP files, Servlets, and enterprise ejbs can also access documents in other Domino systems without logging on to multiple WebSphere domains. By default, SSO is not supported in WebSphere. To implement SSO, You need to configure each WebSphere server. If you need to implement SSO between WebSphere and Domino, you must reconfigure WebSphere and Domino. 3.2 prerequisites To achieve SSO between WebSphere servers, the following prerequisites must be met: 1. All servers must be configured as part of the same DNS domain. For example, if the DNS domain is configured as mydomain.com, SSO will work on all Domino and WebSphere servers, as long as it is on a host belonging to this DNS domain, for example, the two webpshere Servers configured on the hosts a.mydomain.com and B .mydomain.com. 2. all servers must share the user registry. The user registry can be an LDAP database, And SSO between WebSphere servers can also be implemented by users themselves, however, Domino does not support user-defined user registries. Therefore, when implementing SSO between WebSphere and Domino, LDAP databases can only be used as public user registries. [Note] the LDAP database used must be an LDAP database supported by WebSphere. We recommend that you use IBM Security Way. 3. All users are defined in a single LDAP directory. 4. Your browser must support Cookies because the information generated by the server will be transmitted to the client through Cookies and then submitted to other servers accessed by the user for authentication. 5. WebSphere should be version 3.5 or later. 3.3 SSO authorization mechanism The SSO authorization mechanism in WebSphere is relatively simple. A mechanism similar to windows File Permission management is adopted, that is, some roles are defined first, and then these roles are granted permissions to access certain server resources, then, map these roles to specific users or user groups. For example, we have developed a web application on the WebSphere server. The administrator of this application can use the management permissions of this web application, files related to permission management are stored in the/admin directory of the application. Therefore, we can add an admin role to the application to access all files in the/admin directory, then, map the admin role to a group in the LDAP database where all administrator roles are located ,: 4 LDAP database Overview The full name of LDAP is Lightweight Directory Access Protocol, which is generally referred to as LDAP. It is based on the X.500 standard. Unlike X.500, LDAP supports TCP/IP. LDAP standards are organized in the form of a series of RFC (or annotation requests, Request For Comment. For more information about the LDAP-related RFC, see http://www.ldapman.org/ldap_rfcs.html. LDAP information is stored in directories. LDAP is not a relational database. Its information directory structure is similar to a UNIX File System. The structure of this tree-leaf structure makes LDAP very scalable, in addition, the query speed is faster than that of relational databases. Most LDAP servers are specially optimized for read-intensive operations. That is to say, if your application reads a lot of information and modifies little information, you can use the LDAP database. Reading data from an LDAP Server is an order of magnitude faster than reading data from a relational database specially optimized for OLTP. Because it is specially optimized for read performance, most LDAP directory servers are not suitable for storing data that needs to be changed frequently. For example, you can use an LDAP server to store the organization and employee information of a company. However, LDAP is generally not suitable for e-commerce sites as a database server. Detailed LDAP introduction information you can download IBM China's website "LDAP entry" tutorial, is: http://www-900.ibm.com/developerWorks/cn/education/linux/l-ldap/tutorial/l-ldap.zip References: 1. sun's Java ACC specification http://java.sun.com/j2ee/javaacc/ 2. sun JAAS specification http://java.sun.com/products/jaas/ 3. opengroup security implementation part http://www.opengroup.org/security/ 4. ibm ldap getting started tutorial 5. IBM WebSphere documentation center security part http://www-3.ibm.com/software/webservers/appserv/doc/v40/ AE /infocenter/was/pdf/nav_Securityguide.pdf Author information: Name: Xiao Jing contact: 0731-6682346, jing.xiao@chinacreator.com Introduction: I am currently Hunan Changsha Railway Institute of Science and Technology computer system integration Co., Ltd. Software Center Software Engineer, this article mainly studies J2EE programming technology and Web Service technology.

To top

IBM, DB2, VisualAge, and WebSphere are trademarks or registered trademarks of IBM in the United States or other countries or regions.

Microsoft, Windows, Windows NT, and Windows logos are trademarks or registered trademarks of Microsoft in the United States or other countries or regions.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems in the United States or other countries or regions.

The names of other companies, products, and services may be trademarks or service marks of other companies.

IBM copyright and trademark information