"Head First Servlets & JSP" -12-web Application Security

4 key elements of Serlvet security

Authentication, authorization, confidentiality, and data integrity.

Process for the container to complete certification and authorization

There is no security information in the code.

Most Web applications, in most cases, should be handled declaratively by the Web application's security constraints, which are specified in the deployment description document. The reasons are as follows:
Who doesn't want to use XML more?
Can usually be mapped naturally to the existing task roles of the corporate IT department
You can use the previous servlet in a more flexible way
Application developers can re-use the servlet without touching the source code.
Reduce possible maintenance as your application expands
And one more thing, it's just the value of the container.
Support for component-based development ideas

Who is going to implement security in Web applications?

-servlet providers only need to focus on the business

• App Admins only need to determine which roles are in the app (such as Conf/tomcat-users.xml in Tomcat)
• The primary task is borne by the Deployer: Determine which roles have access to which servlets

Steps for authorization

• Security areas
  The security realm, where authentication information is stored, such as Tomcat's Tomcat-users.xml, is read into memory at startup and becomes the memory realm. (The role authentication information can be stored in the file during testing, and the production environment is generally not recommended, but is stored in an LDAP or relational database).
• Tomcat-users.xml file
  
• Start certification
  For the container to ask for the user name and password, the following configuration is required in DD for authentication:
  

• Authorization first step: Defining roles
  Map the roles of the developer (TOMCAT)-specific "user" files to the roles established in the deployment profile.
  As a developer-specific role element in Tomcat-users.xml:
  
  and the servlet specification: the DD security-role element in Web. xml:
  

• Authorization Second Step: Define resource/Method constraints Security-constraint
  declaratively specifies that a given resource/method combination can be accessed by a user of a particular role.
  Security-constraint element in DD:
  
  Key points about Security-constraint child elements web-resource-collection:
  
< The web-resource-collection> element has two primary child elements: Url-pattern (one or more) and Http-method (optional, 0 or more); the
URL pattern and HTTP method define restricted resource requests together; The
Web-resource-name element is necessary, even though you may not use it yourself (you can think of it as being used by the IDE or for future use);
The description element is optional;
The Url-pattern element uses the servlet standard naming and mapping rules (for details about the URL pattern can be seen in the "Deployment" chapter);
You must specify at least one url-pattern, but there can be more than one;
The legal methods for Http-method elements include: GET, POST, PUT, TRACE, DELETE, head, and options;
If no HTTP method is specified, all methods are constrained!!
If you do specify Http-method, only the method you specify is constrained. In other words, once a http-method is specified, the unspecified HTTP method is automatically unconstrained;
One security-constraint can have multiple web-resource-collection elements;
The Auth-constraint element is applied to all web-resource-collection elements in the security-constraint. The


  Auth-constraint element does not define which roles can access resources in Web-resource-collection, instead, It simply defines which roles can make constrained requests.

About Security-constraint child elements auth-constraint child elements:
Auth-constraint Rules:

在security-constraint元素中，auth-constraint元素是可选的；
如果存在一个auth-constraint，容器必须对相关URL进行认证；
如不存在auth-constraint，容器运行不经认证就能访问这些URL；
为提高可读性，可以在auth-constraint中增加一个description元素。


Role-name Rules:

在auth-constraint元素中，role-name元素是可选的；
如果存在role-name元素，它们会告诉容器哪些角色得到许可；
如果存在一个auth-constraint元素，但是没有任何role-name子元素，那么所有用户都遭到拒绝；
如果有<role-name>*</role-name>，那么所有用户都是允许的；
角色名区分大小写。


Duel of multiple Security-constraint/auth-constraint elements

`

1. When you merge a single role name, all of the listed role names allow you to visit
   Ask
2. When the role name "*" is less t-than other settings, everyone is allowed to visit
   Ask
3. Empty (empty, not NO) Auth-constraint tags are not allowed to be accessed when combined with other settings! In other words, the empty auth-constraint is the final "verdict"!
4. If a security-constraint element does not have auth-constraint elements, it merges with other settings, and everyone is allowed access.
   `

   Two different non-null auth-constraint elements are applied to the same restricted resource, then the auth-constraint of all the roles in the two elements run access.
   Restricted access refers to the other parts of the Web app that customers cannot access, but can.
   

See Certification

• 4 Type of authentication
  Basic certification, digest certification, customer certificate certification and form certification.
• Achieve certification
  Declare the authentication mechanism in DD, mainly the login-config element
  

Certification Type Summary

Forms-based authentication

Form login, you can customize your login form page instead of using the other 3 Certified browser login window.

Form login Security Guarantee: HTTPS

To achieve data confidentiality and/or integrity, the Java EE specification guarantees that the transferred data passes through a "Protected transport layer Connection", that is, the container does not have to use any particular protocol to handle the secure transmission. (The HTTPS protocol on top of SSL is practically always used.) ）
Data protection has some overhead and does not encrypt every request and response in your app, so use--conservatively and declaratively--to achieve data confidentiality and integrity:

Data protection

• Unauthenticated customer requests a restricted resource without a transmission guarantee
  
• An unauthenticated customer requests a restricted resource, which is guaranteed by the organic-dense transmission of the resource
  

"Head First Servlets & JSP" -12-web Application Security