PHP SSO SSO development needs to pay attention to the issues

One, single sign-on system development needs to pay attention to the problem

1. Does a single sign-on system need to support JSONP requests?

Single sign-on systems mainly provide user authentication services to other systems, so they need to provide external interfaces. When external systems access through interfaces, cross-domain problems are inevitably involved. Therefore, single sign-on systems need to support JSONP message conversion, that is, they can correctly handle cross-domain requests. Otherwise, the received data fails to be parsed, and Chrome debug displays “Uncaught SyntaxError: Unexpected Token <“.

2. Timeout problem

We provide the CAS open source SINGLE sign-on (SSO) component, which is deployed on two nodes: SSO server (deployed as a Web application) and application system client (deployed as CAS client casclient.jar package and related configuration files). So let’s analyze when a timeout occurs based on the SSO mechanism.

After SSO integration of multiple application systems, during SSO SSO, after successful login, the session of the application system client (the browser client is used as an example) will save the authenticated user context, and the SSO server will generate and cache a user certificate ticket (TGT). The browser client saves a TGC (TGT stored in the browser cookie). The TGT is used as a voucher ticket for SSO access service (ST) issuance. The TGT can be accessed only after the ST is issued.

However, the session of the browser client will timeout (for example, the session timeout value of the general web application client can be set to 30 minutes or longer). After the timeout, the session will be invalid and the user context will be cleared. Because the TGC is still saved in the browser cookie, it will be cleared only after the browser is closed. SSO server timeouts mainly include TGT and ST timeouts. We generally set the timeout values for TGT to 2 hours and ST to 5 minutes.

Generally, when SSO accesses the service for the first time, it carries the ticket parameters. After verifying that the ticket can be accessed normally, the SSO server destroys the ST and invalidates it. The use of TGT tickets is generally kept for a timeout period (2 hours) during normal access, unless a single point of exit destroys the TGT.

Based on the above analysis, we can conclude that SSO timeout mainly involves two elements: session timeout value of browser and TIMEOUT value of TGT. Generally, if the system sets the TGT timeout value > the browser session timeout value, there may be two timeout situations: 1.TGT timeout (the browser session timeout value is small, so it will also timeout); 2. The browser session times out, but the TGT does not. The first one is “1.TGT timeout”. The processing is very simple. The valid voucher of the user is invalid, and the user naturally needs to obtain the valid voucher TGT again.

In this case, the TGT ticket of the SSO server and the TGC (the TGT in cookies) of the browser client are still valid. When SSO visits again, the browser client can carry a TGC (corresponding to the TGT of the server) and resend the ticket ST request to the SSO server. After obtaining the ticket ST, the browser client can normally access the application system with a valid ST ticket. This process is a communication between the browser client and SSO server, which the user may not feel, there is no interruption, as if continuous access, which is to give the user a friendly access experience. If you understand this mechanism, it is the SSO mechanism that actually works in the background.

3. The problem of jsessionid

Jsessionid is an identifier used by Java clients to maintain a session with the application server. Other language clients (such as PHP) have other identifier keywords, which are not well understood. Jsessionid normally exists in the browser cookie (this is done automatically when the Java client connects to the application server). Jsessionid normally does not appear in the URL. The server will retrieve the jsessionID from the client cookie, but if the browser disables cookies, the URL will be overridden. Explicitly rewrite the jsessionID into the Url so that the server can use it to find the session ID.

The CAS open source single sign-on SSO component provides this mechanism. I studied the CAS source code, basically understand the processing mechanism of jsessionID. The general principle is as follows: When a user accesses the service system, the SSO client intercepts the request. When the user is redirected to the SSO server for authentication, the REQUEST path URI is written as “. “Jsessionid = specific session value”, SSO server can distinguish this id value from other client requests, perform authentication processing, return the response to the client cookie and set the jsessionID value. The jsessionID is set in both uri and cookie to double guarantee that the jsessionID value can be set. After the last successful single sign-on, the return business system access address also takes the JsessionID parameter, which looks awkward in the URI address. (1) You can add the parameter “&method=POST” to the request address parameter of the login page address (remember that POST is capitalized here), so that the jsessionID is not displayed in the final access URI.

4. Sometimes subsystems fail to exit normally during single point exit

We know that under normal circumstances, to the user A single sign-on system, normal access to each subsystem, and then execute A single point exits, exit after A successful general jump back to the login page to login again, at this time all has been destroyed, the subsystem of the login session again to log in to another user B, each subsystem should be shown the user data information of the B. However, it is sometimes found that some subsystems still display the data information of user A, which is an occasional phenomenon. Now analyze the possible causes of this situation and find a solution.

5. Some request paths do not require single sign-on filter interception

Business system web application in the use of single sign-on (sso) component, some request path does not need the single sign-on filter interception, such as public open path, don’t need certification has free access to the path, single sign-on mapping path of filter configuration on the wildcard matching path, but to put these paths extracted separately, make filter not intercept single sign-on (sso) processing, It is necessary to expand and transform the original filter to achieve this function.

6. Adaptability of SSO clients is required for different application service implementations

Different application services process requests in different ways. Therefore, the SSO client needs to adapt to the requests that cannot be processed by conventional SSO client methods. In the Web application, a filter casfilter is defined and configured to intercept secure resources. When you log in to the system for the first time or access times out, the request for secure resources is blocked by the filter CasFilter, and the secure resource path is packaged as a service parameter. The SSO server is authenticated by the authentication and ticket verification mechanism. After the authentication succeeds, the login succeeds and continues to access secure resources. When the login attempts to access secure resources again, the Casfilter blocks the access. If the user has logged in based on the user context, the system does not intercept secure resources and accesses them normally. Some applications use other ways to process requests that are difficult to handle in the general way described above. Here is an example of a solution.

6.1. The Ajax client

Companies have a application system using Ajax client to handle the request and response, on a visit to the timeout, Ajax client requests due to the use of asynchronous processing technology (partial refresh the page only), not be able to request a 302 redirect to the SSO server authentication process again, cannot continue to access security resources, has been delayed interface response, Very unfriendly. We adapt for this application. The main points of the transformation are as follows:

We agree on an Ajax request flag for the application system (e.g. AjaxRequestFlag =ajaxRequest) to carry this request parameter with the secure resource Ajax call request, and a timeout request response status value (e.g. 555). The corresponding class of SSO client’s filter casfilter has modified this convention accordingly.

Application system security resource page to introduce file (httpStatussso. js) SSO to Axax request HTTP state processing, including timeout state processing, judging whether to log in, verify tickets, etc., are processed through Ajax request. Which relies on a resource, Ticketvalidate.jsp, to validate tickets.

After the above modification, the security resource of the application system sends a request with Ajax request tags. When a timeout request is made, the SSO client returns a convention response code (555), and the httpStatussso. js file is processed and forwarded to the corresponding login page for re-authentication. Single sign-on access can also function normally. In this way, only the IMPLEMENTATION of the SSO client component is extended, which is compatible with the previous version and ensures the integrity of the SSO component.

6.2. Multi-domain authentication

Sometimes we encounter authentication implementations of different subsystems that have data sources from a user database. Our company is the case, using the Saas model operating software, user authentication is derived from the different tenants or domain, based on this situation, we extend for SSO, main interface provides certification, certification implementation, can make the tenant in certification dynamic corresponding data source, the user is certification process.

6.3. The SSO centralized authentication login page must be customized in the service subsystem

SSO authentication login page default concentration is on the SSO server, style also is not very good, users need to put the login page in custom service subsystem, we to the extension of SSO, mentality is also very simple, mainly is the call will display the default login page, page address into a remote call service subsystem, This address can be configured as a configuration parameter.

Two, about the user registration, need to pay attention to several problems

1. Avoid password leakage

(1) The front-end encrypts the MD5 password and sends it to the background. (2) Back end: when the user information is stored in redis cache during login, it is forbidden to store the password, not to mention to the front-end page.

2. Verification of user registration information (1) front-end verification (2) back-end verification;

3. Possible problems after the launch

1. Cookies may fail to be written. Cause: Nginx lost the domain name when forwarding the request to Tomcat.

When obtaining the requested domain name from the Request object, the real requested domain name was not obtained, causing a cookie writing failure. Procedure User Nginx–>Tomcat lost the requested domain name when Nginx forwards the requested domain name.

The above content hopes to help you, more PHP factory PDF, PHP advanced architecture video materials, PHP wonderful good article can be searched on wechat: PHP open source community

2021 Jinsanyin four big factory interview real questions collection, must see!

Four years of PHP technical articles collation collection – PHP framework

A collection of four years’ worth of PHP technical articles – Microservices Architecture

Distributed Architecture is a four-year collection of PHP technical articles

Four years of PHP technical essays – High Concurrency scenarios

Four years of elite PHP technical article collation collection – database