What is Web application Security – Part 3

‘Web application security’ is part of the ‘Web component developer’ exam and we have already seen two posts relating to it. Recall, that we have already discussed the four authentication methods and the web resource collection element which is part of the authorization. We conclude the discussion of ‘Web application security’ by talking about the authorization constraint and user data constraint in this post.

The different authorization constraints:

Authorization is giving authenticated or unauthenticated roles access to restricted resources. Let us consider the first type of authorization constraint.

  1. Here, roles such as ‘Super user’ and ‘Normal user’ are allowed to access the resources at ‘NewServlet’ protected by the ‘GET’ method. For example, consider the code snippet given below:
    <servlet>
            <servlet-name>NewServlet</servlet-name>
            <servlet-class>NewServlet</servlet-class>
        </servlet><servlet-mapping>
            <servlet-name>NewServlet</servlet-name>
            <url-pattern>/NewServlet</url-pattern>
        </servlet-mapping>

        <security-constraint>
            <web-resource-collection>
                <web-resource-name> Application </web-resource-name>
                <url-pattern> /NewServlet </url-pattern>
                <http-method> GET </http-method>
            </web-resource-collection>

            <auth-constraint>
                <role-name> Super User </role-name>
                <role-name> Normal  User </role-name>
            </auth-constraint>
     </security-constraint>

  2. The second type of authorization constraint is stated as follows:
    <auth-constraint>
          <role-name> * </role-name>
      </auth-constraint>Specifying <role-name> * </role-name> involves giving all roles access to specified resources. It is important to note here that ‘all roles’ means users who have been authenticated. It is specified in the deployment descriptor in the above way.
  3. The third type of authorization constraint where an authorization constraint is specified, but no roles are specified, indicates that none of the roles are allowed access to constrained resources. This is stated as follows:
    <security-constraint>
                  <auth-constraint/>
        </security-constraint>
  4. Not specifying a ‘<auth-constraint>’ element is the fourth type of authorization constraint.  This states that all users in all roles are given access to resources whether they are authenticated or not.
    Having seen the different authorization constraints, let us see what will happen if two different security constraints are specified in a program.   <security-constraint>

          <web-resource-collection>
                  <web-resource-name> Listener </  <web-resource-name>
                     <url-pattern> /chapter01/Listener/* </url-pattern>
                     <http-method> GET </http-method>
            </web-resource-collection>

    <auth-constraint>
        <role-name> Super User </role-name>
        <role-name> Normal  User </role-name>
    </auth-constraint>

    </security-constraint>
    <security-constraint>

          <web-resource-collection>
                  <web-resource-name> Listener </  <web-resource-name>
                            <url-pattern> /chapter01/Listener/* </url-pattern>
                     <http-method> GET </http-method>
     </web-resource-collection>

    <auth-constraint>
        <role-name> * </role-name>
    </auth-constraint>

    </security-constraint>
    </web-app>

    The first <auth-constraint> specifies two roles to access the ‘/chapter01/Listener’ resource and the second <auth-constraint> specifies that all roles are given access to the same resource. In such a case, it is the amalgamation of roles that are given access.

User data constraint:

We have seen how authentication and authorization are implemented to manage web security. Next we see the user data constraint element that is used to implement the security mechanisms of ‘confidentiality’ and ‘data integrity’.

‘Confidentiality’ is making sure that the information that is sent from the sender to the receiver is only received by the receiver and not by other external parties. ’Data integrity’ is making sure that the information is not tampered in transit.

The user data constraint is specified as follows:

<user-data-constraint>
           <transport-guarantee> INTEGRAL </transport-guarantee>
  </user-data-constraint>

The transport guarantee element takes the values of ‘INTEGRAL’, ‘NONE’ OR ‘CONFIDENTIAL’.  ‘CONFIDENTIAL’ makes sure that encryption is enabled on the channel. ‘INTEGRAL’ makes sure that the integrity of the data is preserved.

We have seen the four security mechanisms and their implementations. Enforcing these security mechanisms will make sure that the web applications are more secure.

 

 

About Pavan Gumaste

Pavan Rao is a programmer / Developer by Profession and Cloud Computing Professional by choice with in-depth knowledge in AWS, Azure, Google Cloud Platform. He helps the organisation figure out what to build, ensure successful delivery, and incorporate user learning to improve the strategy and product further.

Leave a Comment

Your email address will not be published. Required fields are marked *


Scroll to Top