Single Sign-on and Rights Management Essence: Session and Cookie introduction

This article begins with the first part of the “Single Sign-on and Rights Management” series: The essence of Single Sign-on and Rights Management. This part mainly introduces related knowledge concepts, abstract processing process, and common implementation framework. Through the introduction of this part, you can have an overall understanding of single sign-on and permission management, and have a basic understanding of its related concepts, processing process and common implementation.

This article introduces session and cookie, which are the basis of login implementation, mainly from the following aspects:

• Basic concepts of session and cookie
• Life cycle of a session
• The scope of a cookie

The cross-domain issue of cookies is covered separately in a future article.

The basic concept

Most systems need to identify the user’s identity. Some functions are available only to specific users, and some functions need to display different content based on the user’s identity. Generally, a unique number is used to identify the user’s identity.

Just like our ID cards, the id number is unique to each person and is generated according to the regulations of the province, city, date of birth, gender and so on. When we go to government agencies, we need to bring our ID cards, and they verify our identity through the ID cards.

Session and cookie are used to identify the user. By default, a unique JSESSIONID is used for authentication. Session is a data structure stored on the server to track the status of users. It can also save some data related to users in memory, cache, database and other storage structures. Cookie is a mechanism by which the client saves user information.

servlet session

The javax.servlet. HTTP package is the main API interface of session. There are mainly the following interfaces:

• HttpSession: The actual session interface definition;
• Session Listener: Some actions, such as create, set properties, invalid, etc., will trigger some events for the corresponding processing;
• Event: When the action is triggered, it is encapsulated as the corresponding Event;

Session-related interfaces are generally implemented by application servers, such as Tomcat, Resin, and Jetty. Main features of Session:

• You can set and get some properties;
• Each session has a unique session ID.
• If the user does not perform any operation for a long time, the maintenance timer will clear the session to ensure timely release of resources.
• You can actively clear a session by calling the invalidate method;

In Tomcat, HttpSession is implemented as StandardSession, and StandardSession implements the custom Session interface, which is a wrapper around HttpSesion.

In addition, Tomcat will implement session management and persistence, and the corresponding session can be obtained at any time. The specific implementation will not be analyzed in this article, but there are many articles on the Internet.

cookie

Cookie is a solution for the client. It is the special information sent by the server to the client. These information are stored in the form of text files on the client.

The server uses HTTPResponse to set the cookie to the response header and sends it to the client, which then automatically sets the cookie to the request header. The following is the cookie information after I logged in Baidu:

Cookie also has expiration time, which can be set on the server through cookie.setmaxAge (expiry), expiry=-1: means that the cookie will expire after the browser is closed; Expiry >0: the representative will save the cookie to the hard drive and it will not be automatically deleted by the browser until the set time expires; Expiry =0: delete the cookie, the cookie will be deleted by the browser.

There are several other features:

• SetDomain: Sets the cookie range, more on this later;
• IsHttpOnly: Indicates whether only HTTP protocol is used. GetCookies () can only be obtained on the backend, not js;
• Each cookie file size: 4KB, if more than 4KB browser does not recognize;
• Cookies are insecure and may leak user information. The browser supports disabling cookie operations.
• Temporary session: Default lifetime for which cookies are destroyed when the browser is closed

The interaction process

1. Use the browser to access the server page;
2. After receiving the first request from the client, the server creates a session and generates a unique SESSION ID.
3. At the same time, set the cookie in the response request with the attribute name jessionID;
4. When the client receives the jessionID, it will save it. When the client requests the jessionID again, it will set it in the header and the server can obtain it from the request header.
5. The server verifies whether the obtained sessionId exists to verify whether it is the same user.

When cookies are disabled by the browser, cookie-based sessions will not work properly and a new session will be created each time. The JSessionID can be passed through url rewriting.

Life cycle of a session

Sessions are stored on the server, and are created when the user accesses them for the first time. Sessions are created when the user accesses JSP, servlet, etc., and are not created when the user accesses static resources such as HTML and images. Call request.getSession(true) to force Session generation.

The server will remove a Session from memory if it has not been active for a long time. By default, a Session in Tomcat is invalid for 30 minutes. You can call the invalidate method of calling Session to force it to be clear.

In addition, we can implement session lifecycle management ourselves to meet specific business requirements, such as single sign-on, distributed sessions, etc., which Tomcat provides extensions for, which will be covered in future articles.

The scope of a cookie

When creating a cookie, you need to set the domain. If there are multiple levels of domain names, you can control the scope of the cookie. If the site request volume is large, set the cookie scope is inappropriate, will waste a lot of traffic.

For example, there is a tier 3 domain name (support.kefu.mi.com), where mi.com is the tier 1 domain name and kefu.mi.com is the tier 2 domain name.

Cookie setting in three types of domain names, set different domains, see the effectiveness of the cookie when accessing the domain name at each level. When domain is set to null, domain defaults to the current domain name.

Set a cookie under the tier 1 domain mi.com

If the domain is a level-1 domain name, the level-1 domain name and its subdomains can receive cookies. However, when the domain parameter is set to a subdomain, all domains cannot receive the domain name, including the subdomain name.

Set a cookie under the secondary domain kefu.mi.com

When a domain is its own domain name, its parent domain name cannot receive cookies, but its own domain name and its subdomain name can receive cookies. When the subdomain name or other domain name is set, all domain names cannot receive cookies.

Set cookies under the tertiary domain name McC.kefu.mi.com

It can be concluded that the domain parameter can set the parent domain name and its own, but can not set other domain names, including subdomains, otherwise the cookie does not work.

Series index:

1. This section describes sessions and cookies
2. HTTP redirection
3. Introduction to single sign-on
4. Cookie Security Issues
5. Introduction to Rights Management