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

The main content of this article is "Tomcat container security authentication and authentication explanation", interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "Tomcat container security authentication and authentication explanation" it!

1. Authorization

Containers and Web applications use role-based access control, in which containers need to achieve the functions of authentication and authentication, while Web applications need to achieve the function of authorization.

Two authorization methods are described in the Servlet specification: declarative security and programmatic security. Declarative security is the declaration of roles, resource access, and authentication in the deployment descriptor. The following code snippet is taken from the web.xml of the Manager application that comes with Tomcat:

HTML Manager commands / html/* manager-gui BASIC Tomcat Manager Application The role that is required to access the HTML Manager pages manager-gui

These security-related configurations are initialized and set to the StandardContext object when the application is deployed. For more details, see the specification's explanation of the deployment description file, and then take a look at how Tomcat designs and implements authentication and authentication.

two。 Design of authentication and authentication

Although the Servlet specification describes the mechanism for Web applications to declare security constraints, it does not define the interface between the container and the associated user and role information. Therefore, Tomcat defines a Realm interface that adapts to various sources of authentication information. The class diagram of the overall design is as follows:

In the figure above, the core methods of each class are included. The functions of the key classes or interfaces are as follows:

Realm-translated as a domain, a domain generally refers to a scope in which user names, passwords, roles and permissions are stored, and authentication is provided. Typically, this scope can be a configuration file or database

CombinedRealm-contains one or more Realm internally, and authentication is performed in the order of configuration. Any successful Realm verification indicates successful verification.

LockOutRealm-provides a user lockout mechanism to prevent too many failed authentication attempts in a certain period of time

Authenticator-the interfaces for different authentication methods, mainly implemented by BASIC, DIGEST, FORM and SSL

Principal-an abstraction of the authentication principal, which contains user identity and permission information

SingleSignOn-single sign-on feature to support multiple applications in the container

2.1 initialization

Realm is a nested component of a container that can be nested in Engine, Host, and Context, and child containers can override the Realm configured by the parent container. The default server.xml configures an LockOutRealm composite domain in Engine with an internal UserDatabaseRealm that extracts user information from the configured global resource conf/tomcat-users.xml.

The security constraints declared in web.xml are initialized to the corresponding SecurityConstraint, SecurityCollection, and LoginConfig objects and associated to a StandardContext object.

As you can see in the figure above, AuthenticatorBase also implements the Valve interface, and if a StandardContext object is found to have declared a standard verification method during configuration, it will be added to its own Pipeline.

3. One request for authentication and authentication process

Context represents a Web application within Tomcat. If the configuration uses BASIC verification method, then the Pipeline inside Context has two valves, BasicAuthenticator and StandardContextValve. When a request is made to enter the Context pipeline, authentication and authentication will be carried out first. The method is called as follows:

The core code of the whole process is in the invoke method of AuthenticatorBase:

Public void invoke (Request request, Response response) throws IOException, ServletException {LoginConfig config = this.context.getLoginConfig (); / / 0. Whether an authenticated Principal if (cache) {Principal principal = request.getUserPrincipal (); if (principal = = null) {Session session = request.getSessionInternal (false); if (session! = null) {principal = session.getPrincipal (); if (principal! = null) {request.setAuthType (session.getAuthType ()); request.setUserPrincipal (principal) is cached in the object. }} / / for special cases where form-based login may be outside the security domain, String contextPath = this.context.getPath (); String requestURI = request.getDecodedRequestURI (); if (requestURI.startsWith (contextPath) & & requestURI.endsWith (Constants.FORM_ACTION)) {return }} / / get the security domain object. The default configuration is LockOutRealm Realm realm = this.context.getRealm (); / / the security constraint SecurityConstraint [] constraints = realm.findSecurityConstraints (request, this.context) of the configuration is attempted according to the request URI. If ((constraints = = null) / * & & (! Constants.FORM_METHOD.equals (config.getAuthMethod () * /) {/ / indicates that the resource accessed by null has no security constraints and directly accesses the next valve getNext () .invoke (request, response); return } / / ensure that constrained resources are not cached by Web agents or browsers, as caching may cause security vulnerabilities such as if (disableProxyCaching & &! "POST" .equalsIgnoreCase (request.getMethod () {if (securePagesWithPragma) {response.setHeader ("Pragma", "No-cache"); response.setHeader ("Cache-Control", "no-cache") } else {response.setHeader ("Cache-Control", "private");} response.setHeader ("Expires", DATE_ONE);} int I; / / 1. Check the transmission security constraints of user data if (! realm.hasUserDataPermission (request, response, constraints)) {/ / Verification failed / / Authenticator has set the appropriate HTTP status code, so we don't have to do anything special return;} / / 2. Check to see if authorization constraints are included, that is, role verification boolean authRequired = true; for (iSyn0; I < constraints.length & & authRequired; AuthConstraint +) {if (! intss.getAuthConstraint ()) {authRequired = false;} else if (! intss[ I] .getAllRoles ()) {String [] roles = originints[ I] .findAuthRoles (); if (roles = = null | | roles.length = 0) {authRequired = false } / / 3. Authentication username and password if (authRequired) {/ / authenticate is an abstract method that implements if (! authenticate (request, response, config)) {return;}} / / 4 by different authentication methods. Verify that the user contains the authorized role if (! realm.hasResourcePermission (request, response,constraints,this.context)) {return;} / / 5. Any and all specified constraints getNext (). Invoke (request, response);} have been met

In addition, AuthenticatorBase also has a more important register () method, which will set the Principal object generated after authentication to the current Session, if the SingleSignOn single sign-on valve is configured, and associate the user identity and permission information to the SSO.

4. Single sign-on

Tomcat supports access to all Web applications deployed on the same virtual host with a single authentication, which can be achieved through the following configurations:

......

Tomcat's single sign-on is implemented using Cookie:

When any Web application is successfully authenticated, the user identity information will be cached in SSO and a Cookie named JSESSIONIDSSO will be generated.

When the user visits the host again, the stored user token will be taken out through Cookie, the user Principal will be obtained and associated to the Request object

In a stand-alone environment, there is no problem. In a cluster environment, Tomcat supports Session replication, so will the information related to single sign-on be replicated synchronously? Later, we will continue to analyze the principle and implementation of Tomcat cluster.

5. Summary

This article describes login authentication and permissions implemented within Tomcat, while applications usually log in through Filter or custom interceptors (such as Spring's Interceptor), or use third-party security frameworks, such as Shiro, but the principles are similar.

At this point, I believe that everyone on the "Tomcat container security authentication and authentication explanation" have a deeper understanding, might as well to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.