Shulou(Shulou.com)06/02 Report--

1.1 comparison of single sign-on principle and technical implementation 1.1. 1 single sign-on principle

Single sign-on (SSO) means that a user only needs to authenticate once to access all authorized resources without multiple authentication. SSO mechanism can reduce human error and improve the security of the whole system. Although SSO is valuable, its implementation is not easy because so far there is no unified standard for user authentication. IBM WebSphere Portal server provides various means to make the implementation of SSO simple, secure and effective.

There are usually two methods: external proxy and built-in proxy.

1. External agent

In some cases, you can use a mediation-like proxy process that lies between the user and the application, as shown in figure 1-1. When the user is asked by the application to provide proof of identity, the agent process obtains the user's letter of credit from the user's database and sends it to the application. A letter of credit is equivalent to a token that contains only the user's identity information and no user's password credentials. In other words, using an external agent to achieve single sign-on, the integrated Web application system will no longer verify the user's password in the Web application system. It believes that as long as you are a legitimate user of Portal and successfully logged in to Portal, you only need to tell me your identity and role, and I think you are a legitimate user in the Web system who can use authorization information.

Figure 1-1 Portal server performs authentication process-- Web application does not provide Authentication API

The ① user logs in to the portal server and the authentication service authenticates the user.

The ② verification passed, established the user's letter of credit, and requested the establishment of the user's default desktop.

The ③ agent uses the user's letter of credit and sends a request to the directory service to get the user name and password of the Web application.

④ gets the user name and permission information.

The ⑤ agent uses them to enter the Web application and get the application data according to the permission information.

The ⑥ agent formats the data and generates the user's default desktop, and the content of the application is presented in the form of portal Channel.

⑦ delivers the generated desktop to the user.

The above situation applies when Authentication API is not provided in Web applications. For Web applications that provide Authentication API (such as Lotus Notes), there is one more step, that is, step 4: authentication. The user name and password of the user in the Web application must be stored to the Portal platform through the encrypted storage mechanism in advance, and the credit certificate established by the agent also contains the password of the user in the Web application system. The agent program calls the Web authentication service with the user name and password of this user to realize the authentication process. After the authentication is completed, what rights the user has in the Web system will be executed by the next Web system, because at this time the user has successfully logged in to the Web application system by calling the authentication service. As shown in figure 1-2.

Figure 1-2 Portal server performs authentication process-- Authentication API provided by Web application

The ① user logs in to the portal server.

② requests the establishment of a user default desktop.

The ③ agent uses Portal Token and approves the use of Authentication API for user authentication using the Web application. The user name used is the same as when logging in to the portal server, or it is a mapping value, and the mapping table should be stored in the Profile of the portal server.

④ authenticates users.

⑤ authentication is successful.

The ⑥ agent uses the Web application API to get the data.

The ⑦ agent formats the data and generates the user's default desktop, and the content of the application is presented in the form of portal Channel.

⑧ delivers the generated desktop to the user.

The agent program mentioned above can be realized through the Servlet program written by API provided by IBM WebSphere Portal. This Servlet program passes the user's letter of credit to the application and redirects the user to the application's main page.

Advantages of external agents:

-start-up investment is relatively small.

Disadvantages:

-it is not conducive to system management and maintenance.

-affect the overall performance of the system.

-Cross-domain SSO is not supported.

2. Built-in agent

The built-in agent method refers to the use of policy management software, namely Identity server software. The policy management software works by placing an agent module (Agent Module) on the Web server, which is responsible for user authentication and authorization information together with the Identity server.

To integrate the policy management software with the Portal server, you can install the policy agent module embedded on the Web server in the Portal server, and use the API provided by the Portal server to generate an effective Portal server S ession based on the S ession creation process of the policy management software. In this way, users can access any W eb application under the control of the policy management system.

Advantages of built-in agents:

-user authentication and resource access can be safely and effectively controlled through the Identity server and its Web proxy module.

-provide centralized access control management to enhance the manageability and efficiency of large and complex application systems.

-provides a simple way for system developers to access centralized directory resources, which is easy to expand.

-through Extranet Web Agents, Web applications can be seamlessly integrated.

-it has good system scalability to support millions of users.

-protect investment.

-support cross-domain SSO.

Logically, the Identity server is the core application access controller of the enterprise, while the Portal server is a content aggregator that aggregates applications protected by Identity servers. At the same time, the Portal server also acts as a secure application access transporter within the enterprise. The principle and process of using built-in agent to implement Portal and Web application system are as follows, which is introduced in 12 steps.

① users access the portal gateway.

The ② portal gateway checks whether the current IPS Session contains a valid Cookie, and if it does not (that is, the Session has not been established), the portal gateway passes the packet to the authentication module of the portal server.

The authentication module of the ③ server forwards the packet to the proxy module of the Identity server.

The ④ agent module sends a customized login page to the user (this page shows using the Identity server for authentication).

The ⑤ user enters a user name / password (or other identity information) and returns it to the agent module.

The ⑥ proxy module sends this information to the Identity server.

The ⑦ Identity server authenticates the user (queries the directory database where the user information is stored).

⑧ verification is successful, and the Identity server generates Identity Cookie (including information such as successful verification) and sends it to the agent module.

The ⑨ proxy module stores the Identity Cookie and invokes the portal server's authentication module to make the Session valid (generate a Portal Session).

The authentication module of the ⑩ portal server sends Identity Session and Portal Session to the user's browser.

The ⑪ portal gateway saves the Portal Session to enable the user's Session to take effect.

The ⑫ portal gateway sends the portal home page to the user.

Once the authentication process is completed, users can access any resources and applications protected by portal servers and Identity servers without re-authentication.

3. Single sign-on based on page flow

Single sign-on based on page flow means that after a user successfully logs in to Portal, every time the user invokes the page of the Web system in the business system, the Web system will contact the agent for verification. IDSAME products provide this function, it is a more stringent access control policy, which is used to protect the data and resources of the core and important systems of the enterprise. The specific implementation is accomplished by iDSAME's Web agent and the corresponding URL access policy.

The Web agent is installed on the machine of the protected resource, and when the user accesses the protected system resource, the Web agent first intercepts the request to check whether the access is a protected resource, and if not, allows access; if so, iDSAME checks whether the user can access or not based on the user's Token. Different from built-in agent and external agent, using this strategy to achieve single sign-on will seriously reduce the performance of the application system, because every time a user visits a page, it will cause a process of authentication. Usually, this situation is applied to the core and important business systems of the enterprise.

4. Cross-domain single sign-on

Cross-domain single sign-on (Cross Domain SSO) means that several application servers that implement single sign-on are in different domains. In this case, in order to achieve single sign-on, other domains must be converted to the local domain for domain name mapping. The schematic diagram of the cross-domain single sign-on implementation is shown in figure 1-3.

Figure 1-3 schematic diagram of the implementation of single sign-on in cross-domain

1.1. 2 Technical solution of single sign-on

For different integrated application systems, we will provide different single sign-on solutions. Here are the common technical solutions to achieve single sign-on function.

1. LTPA (Lightweight Third-Party Authentication) token ring technology

LTPA is a token ring, which records the user's login information and identity information. It provides a lightweight third-party authentication mechanism based on Cookie (LTPA). When a user makes a request for resources, he must first authenticate to the authentication server. After successful authentication, the authentication server generates LTPA Cookie on behalf of the user. LTPA Cookie, as an authentication tag service, contains user identification, key and tag data, buffer length and expiration information, which is encrypted using a password-protected key shared between the authentication server and the application system. The authentication server inserts a Cookie in the HTTP header of the request, which is sent to the application system through a connection, and the application system server receives the request, decrypts the Cookie and authenticates the user based on the identification information provided in the Cookie.

2. Form-based single sign-on (Form-Based SSO)

The form-based single sign-on (Form-Based SSO) feature allows authentication servers to transparently log authenticated users into background systems that need to be authenticated by HTML forms. The schematic diagram of the form-based single sign-on implementation is shown in figure 1-4.

Figure 1-4 schematic diagram of form-based single sign-on implementation

3. HTTP header file (HTTP Header) technology

Using the authentication method of HTTP Header, the authentication server can transmit the authenticated user identity information (including account number, attribute information, etc.) to the background application system through HTTP Header, and the background application system can intercept these user information from HTTP Header to confirm the user identity, so as to realize the function of unified authentication (single sign-on). This unified authentication method requires the corresponding modification of the background application system, so that it can obtain the user information in HTTP Header.

4. Voucher vault (GSO-Lockbox) technology

GSO-Lockbox as a way to achieve single sign-on is generally used together with Form-Based SSO, mainly considering that everyone's user identity may be inconsistent in each system, and this problem can be solved in this way. Using GSO-Lockbox, the corresponding relationship between user identity information and background application system can be established.

There are different implementations in different products, for example, called Credential Vault in IBM WebSphere Portal, which is also translated as "voucher vault". The credential vault creates a credential insurance segment for each application system that implements single sign-on, and a credential slot for each Web user in each credential insurance segment. A slot is the smallest credential unit used to store a user's user name and password key-value pair in an application system (see Table 1-1).

Table 1-1 how GSO-Lockbox implements single sign-on

It is difficult to say who is the best in the above ways. The best practice is to choose different solutions according to the specific situation of the customer, or several implementation schemes are used at the same time, depending on different application systems. Generally speaking, however, the following principles should be followed.

(1) for applications deployed on WebSphere Application Server, WebLogic Server, SAP NetWeaver Application Server, Domino and other servers that can identify LTPA token rings, and the user directory is the same as the user directory of Portal, or there is an one-to-one corresponding concern, when implementing single sign-on with Portal, it is recommended to use LTPA mechanism.

(2) for applications deployed on WebSphere Application Server, WebLogic Server, SAP NetWeaver Application Server, Domino and other servers, and the user directory is not the same as the user directory of Portal, or there is no one-to-one corresponding application system, it is recommended to use JAAS authentication when implementing single sign-on with Portal.

(3) the user registry is not consistent with Portal, but when all users in the application system have corresponding users in Portal, credential vault technology is recommended regardless of whether their user name arrangement rules are consistent or not.

1.2 Application of single sign-on in best project practices

After using single sign-on technology to realize single sign-on between Portal system and other application systems, as long as users successfully log on to Portal, they can directly enter the application system without logging in again, or directly use the authorized application or information in the application system in Portal. In the actual project development, the following modes are usually designed as extended applications of single sign-on and single sign-on.

1.2. 1 enter the home page of the application system in the form of list

Entering the home page of the application in the form of a list refers to providing a Portlet that displays a list of applications, listing all the applications that implement single sign-on (see figure 1-5). Click the entry in the list to enter the application directly on the new page without having to log in again or provide any credentials.

Figure 1-5 apply single sign-on as a list Portlet

1.2. 2 directly enter the deep integration mode of each application system

In many cases, users need to go to a deep page of the system instead of clicking step by step from the home page of the system. The deep integration mode of single sign-on refers to going directly to the page that the customer wants to enter through different tags, as shown in figure 1-6.

Figure 1-6 Click different tabs to go directly to the deep integration page of the application system

1.2. 3 combed and integrated in the way of application navigation

Many customers have the experience that when there are too many applications, they forget which system the page that initiates a business or function is in. The idea of application navigation integration refers to not combing deeply integrated pages from the perspective of application systems, but analyzing them from the perspective of users' business applications, combing and classifying the functional pages frequently used by users from the perspective of business. and show it to the system by category. Users only need to know what to do, regardless of which system the page to be executed is in. In other words, let the user forget the existence of the system. Figure 1-7 shows a typical application navigation diagram.

Figure 1-7 typical application navigation diagram (application navigation allows users to forget the existence of the system and just know what to do)

1.2. 4 as a universal verification logic unit when calling the task processing interface for a unified to-do task

The most extensive and in-depth application of single sign-on is to unify the work to do. In all systems, the to-do items that each user needs to do are classified according to the business domain, and are centrally displayed in each column, so that the to-do items that users originally need to log in to multiple systems to deal with are completed in one column. How convenient! Figure 1-8 shows a typical scenario that integrates to-do items from dozens of systems into one column and divides them into nine business domains.

Figure 1-8 shows the to-do items from dozens of systems in one column according to the business domain

1.3 Development / configuration guidelines for single sign-on technology

There are many technologies to implement single sign-on, such as JAAS authentication, but the most widely used in the project practice are LTPA token ring and vault technology. This section details the development / configuration process for both scenarios.

1.3.1How does LTPA realize the working mechanism of 1.3.1.1 LTPA for SSO

The LTPA mechanism is suitable for applications deployed on WebSphere Application Server, WebLogic Server, SAP NetWeaver Application Server, Domino and other servers, which can identify LTPA token rings and applications where the user directory and the Portal user directory are the same or have an one-to-one correspondence. This section takes the implementation of single sign-on between WebSphere Portal and Domino as an example to describe how the LTPA mechanism is configured.

LTPA (lightweight third Party Authentication) is a token ring that is enabled by using Domain Cookie. This encrypted session C ookie is placed in the user's browser and contains some information that the WebSphere or Domino Application server can encrypt and use to indicate that the user has passed the authentication in the DNS (Domain Naming Service, domain name service) domain covered by the C ookie.

LTPA C ookie contains the following information.

-Cookie name: always set to LtpaToken.

-Domain: set to the Internet domain, which is shared by all servers participating in single sign-on (for example, mycompany. Domain. Com).

-Cookie expiration: set to delete the Cookie when the browser terminates.

-Security: set on to force the use of secure Sockets layer (SSL). The LTPA configuration has a setting parameter to create a C ookie that is sent only through SSL.

-Cookie value: is set to the LTPA tag.

The LTPA tag is an encrypted string that contains the following information.

-user data: generally set to user ID, but it can also be any user information used to uniquely identify the user.

-Expiration time: unlike Cookie expiration, this field is used to impose a time limit calculated from the moment you log in, regardless of browser activity or inactivity. This time limit is a settable LTPA configuration, which is 30 minutes by default.

1.3.1.2 how to configure SSO between Portal and Domino

The SSO of Portal and Domino can be realized by configuring LTPA. Generally speaking, after a user logs in to the Portal system, the Portal system will encrypt the user's login information into LTPA and store it in a certain location. When the user continues to access the authorized resources in the Domino system, the Domino system will automatically read the LTPA of that location, read it and decrypt it and then get it to the Domino system for verification. If the authentication passes, it will be displayed to the user with authorization information. So it is very easy to configure SSO between Portal and Domino, as long as you export and store the LTPA of the Domino system server as a .key file, and then import it into the server where the Portal system resides (WebShpere Application Server).

1.3. 2 how the vault technology is implemented is 1.3. 2.1 Overview

WebSphere Portal provides the Credential Vault (credential vault) function, and Credential Vault passes the user name and password to the back-end application through Basic Authentication Header. In order for the Domino server to accept the credentials passed through this header, the server session authentication must be configured to Single-Server mode. In Multi-Server mode, the server only accepts credentials that are passed through the LTPA mechanism. Therefore, in order to use Credential Vault for SSO with Domino applications, you must configure Domino server session authentication to Single-Server mode.

To use Credential Vault, the user needs to enter some credentials, which is enough for once. These credentials are then stored in an encrypted database table and are passed to the back-end application whenever the user accesses the P ortlet. For details on configuring Credential Vault, see WebSphere Portal InfoCenter.

1.3.2.2 implement SSO principle in voucher vault

Let's take the simplest SSO process as an example.

The login process of Putong business system: the system first provides a page for us to enter user information in the application.

After the user enters the user name and password, click the "login" button, and the page is submitted to the Action (check_login.jsp) corresponding to form for processing. Let's take a look at the code of check_login.jsp.

Next, submit it to the database to verify the validity of the user information, and if it is legal, navigate to the authorization information page; otherwise, relocate to the login page login.jsp.

How do you solve this problem in Portlet development?

In fact, it is the check_login.jsp page that plays a key role, which needs to get the two key values of the user name and password, and then take these two parameters to the background database to verify. In a normal login method, these two parameters are obtained through login.jsp. In fact, login is automated as long as Portlet can provide these two keys for the page. It is very easy for Portlet to get these two parameters, so it is very easy to implement single sign-on. We can copy a check_login.jsp file, such as check_portal_login.jsp, the two parameters of this page are provided by Portlet, and leave the rest to the business system. We don't have to take care of page flow and full-line control.

1.3.2.3 the method of developing Portlet to realize SSO

(1) transfer URL with JSP values

We develop a Portlet that uses system-specific slots, use the relevant interfaces of the voucher to extract the key values stored in the voucher in PortletView.jsp, and then transmit them to iFrame in the form of URL.

Part of the code for PortletView.jsp is as follows:

If the user has stored the key value in the credential vault, when the View.jsp page of the Portlet is initialized, the iFrame will display the authorization information after the user has successfully logged in, that is, the SSO has been implemented.

(2) the value of Class is written to Session, which is taken out by JSP and transmitted by URL

We get the key-value pairs stored by the user in the voucher vault in the control class of Portlet and write Session in the doview () method of PortletView. Take the Session from the V iwe.jsp of Portlet and transfer it to the destination agent as URL, as in the first method.

(3) Class writes Session, and single sign-on agent takes Session.

We get the key-value pairs stored by the user in the voucher vault in the control class of Portlet and write Session in the doview () method of PortletView. On the other hand, the assisted login page developed specifically for Portal will take out the user's credentials directly from Session and skip the specific operation method.

As these methods are relatively simple to develop, I will pass them over here and will not introduce them in detail.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.