Spring Security Primer (1-13) Spring security-session Management

Session Management

Spring Security provides support for HTTP session management through child element session-management under the HTTP element.

Detect Session Timeout

Spring Security can direct a user to a specified page when the user makes a request using a sessionId that has timed out. This can be done with the following configuration.

   <security:http>      ...      <!-- session 管理，invalid-session-url 指定使用已经超时的 sessionId 进行请求需要重定向的页面 -->      <security:session-management invalid-session-url="/session_timeout.jsp"/>      ...   </security:http>

Note that the session Timeout redirect page should not require authentication, or redirect to the Session Timeout page will go directly to the user login page. In addition, if you use this method to detect the session timeout, when you exit the login and then log back in without closing the browser, Spring Security may incorrectly report that the session has timed out. This is because even if you have logged out, but when you set the session to be invalid, the cookie that holds the session information is not cleared, and the previous sessionId will be used for the next request. The workaround is to display a defined user to delete the corresponding cookie that holds the session information when exiting the login.

   <security:http>      ...      <!-- 退出登录时删除 session 对应的 cookie -->      <security:logout delete-cookies="JSESSIONID"/>      ...   </security:http>

In addition, Spring Security does not guarantee that this is valid for all Servlet containers, and that it does not work on your container and requires you to experiment on your own.

Concurrency-control

Typically, in your app you may only want one user to log in to your system successfully at the same time, and the usual behavior is that the last login will invalidate the previous login, or limit the last login. The session-management of Spring Security provides us with this limitation.

First, we need to define the following listener in Web. Xml.

   <listener>   <listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>   </listener>

Under the session-management element, there is a concurrency-control element that restricts the number of authenticated sessions that the same user is allowed to exist in the application at the same time. This value is 1 by default and can be specified by the Max-sessions property of the Concurrency-control element.

   <security:http auto-config="true">      ...      <security:session-management>         <security:concurrency-control max-sessions="1"/>      </security:session-management>      ...   </security:http>

The default policy for Spring Security is to invalidate the previous setting when the number of authenticated sessions that the same user exists at the same time exceeds the value specified by Max-sessions. If you want to restrict users from logging on again, you can set the value of Concurrency-control error-if-maximum-exceeded to True.

   <security:http auto-config="true">      ...      <security:session-management>         <security:concurrency-control max-sessions="1" error-if-maximum-exceeded="true"/>      </security:session-management>      ...   </security:http>

Set error-if-maximum-exceeded to True after you have logged in and then want to log in again, the system will reject your login and redirect to the one specified by Form-login Authentication-failure-url. If you re-login is done through remember-me, then will not go to Authentication-failure-url, but return an unauthorized error code 401 to the client, if you still want to redirect a specified page, then you can The Session-authentication-error-url property of the session-management is specified, and you need to specify that the URL is not managed by Spring Security, which is set its secure= through the HTTP element non E ".

   <security:http security="none" pattern="/none/**" />   <security:http>      <security:form-login/>      <security:logout/>      <security:intercept-url pattern="/**" access="ROLE_USER"/>      <!-- session-authentication-error-url 必须是不受 Spring Security 管理的 -->      <security:session-management session-authentication-error-url="/none/session_authentication_error.jsp">         <security:concurrency-control max-sessions="1" error-if-maximum-exceeded="true"/>      </security:session-management>      <security:remember-me data-source-ref="dataSource"/>   </security:http>

In the above configuration we have configured Session-authentication-error-url as "/none/session_authentication_error.jsp", and we have specified all URLs starting with "/none" are not controlled by Spring Security, so that when the user logs in, the automatic login via remember-me is redirected to "/none/session_authentication_error.jsp".

In the above configuration why do we need to specify that our Session-authentication-error-url is not controlled by Spring Security? Do you want to change it? This involves the difference between the two described earlier. The former indicates that no spring security filter is used, and naturally there is no need to pass the Spring security certification, which is filtered by spring Security's filterchain, except that its corresponding URL can be accessed anonymously. That is, you do not need to log in to access. When using the latter, Remember_me_filter detects that the user is not logged in and provides information about the REMEMBER-ME, which will enable Remember_me_filter to log on automatically, Then at the time of automatic login because we restrict the same user to log in only once at the same time, the latter will be denied login, this time will be redirected to Session-authentication-error-url, redirect access When Session-authentication-error-url, the Remember_me_filter will automatically log in, thus forming a dead loop. So the session-authentication-error-url should be set to not be controlled by Spring Security, but not used.

In addition, you can specify the page to jump from when a user tries to use a session that causes the session to time out due to its login again by using the Expired-url property. Also be aware that setting the URL is not required for authentication.

   <security:http auto-config="true">      <security:form-login/>      <security:logout/>      <security:intercept-url pattern="/expired.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY"/>      <security:intercept-url pattern="/**" access="ROLE_USER"/>      <security:session-management>         <security:concurrency-control max-sessions="1" expired-url="/expired.jsp" />      </security:session-management>   </security:http>

Session Fixed attack protection

Session pinning means that after the server has created a session to the client, they will communicate through the session before the session expires. Session fixed attack refers to a malicious attacker first by accessing the app to create a session, and then let other users use the same session to log in (for example, by sending a link containing the sessionId parameter), after the other user successfully logged in, the attacker takes advantage of the original The SessionId access system will have the same permissions as the original user. Spring Security, by default, protects the session fixed attack by re-creating a new session for the user when they log in. If your application does not require this protection or if it conflicts with some of your needs, you can change its protection strategy by session-management the Session-fixation-protection attribute. There are three optional values for this property.

• Migratesession: This is the default value. It indicates that a new session will be created after the user logs in, and the attribute in the original session will be copied to the new session.
• None: Indicates continued use of the original session.
• NewSession: means to recreate a new session, but not copy the attribute owned by the original session.

Spring Security Primer (1-13) Spring security-session Management