Web application Security – II

News & Updates / By

We have already seen a few basics of web application security in Java in an earlier post. We will continue this post by extending the same discussion. We will discuss the two remaining authentication mechanisms followed by authorization.

CLIENT-CERT AUTHENTICATION:

The CLIENT_CERT authentication method is yet another way of authenticating the user. Compared to the BASIC and FORM based authentication, this is the most secure form of authentication.

 Here the server authenticates the user by checking their public key certificate. The public key certificate is generated by an issuing authority such as the ‘certificate authority’ (CA) The CLIENT-CERT authentication uses HTTP over SSL which is a secure form communication between the client and server. If one is deciding to use CLIENT-CERT form of authentication it is necessary to ensure that the client has a public key certificate.

It is specified in the deployment descriptor in the following way:

<login-config>

        <auth-method>DIGEST</auth-method>

    </login-config>

DIGEST AUTHENTICATION:

The ‘Digest’ form of authentication is similar to the BASIC form of authentication. The DIGEST form of authentication also uses the browser’s pop-up window for entering the ‘username’ and ‘password’.  But unlike the ‘BASIC’ of authentication, the passwords are not transmitted in unencrypted format. A cryptographic hash of the password is sent by the client to the container thereby ensuring better security for the application.

In the deployment descriptor, the ‘DIGEST’ form of authentication is specified the following way:

    <login-config>

        <auth-method>DIGEST</auth-method>

    </login-config>

Having seen the various authentication mechanisms, we will next move to the authorization part of web security in Java.

AUTHORIZATION:

Authentication is just a part of providing security for web applications. Authorization is the next stage, wherein users based on roles are allowed access to specific resources. Let us understand this by means of an example:

In any business organization, it is the employee’s hierarchy that allows them access to specific resources. In the banking sector, a ‘teller’ might be allowed access to limited resources while the ‘manager’ might be given access to more resources.

‘Manager’ and ‘teller’ are roles here. It does not matter who the ‘manager’ is or who the ‘teller’ is – it is just that their roles determine their access.

This can be declaratively specified in the deployment descriptor by the following elements:

  1. Web resource collection specified by :
    <web-resource-collection> element
  2. Authorization constraint specified by
    <auth-constraint> element

Let us discuss the elements of authorization which are vital for web security. 

Web resource collection:
The element <security-constraint> is used to represent the elements of authorization and confidentiality. We will first discuss the authorization requirements of the security constraint element.
The URLs which are meant to be protected and the HTTP methods which protect them are stated in the web resource collection. This is the syntax of the web resource collection:

<web-app>

   <security-constraint>

      <web-resource-collection>

              <web-resource-name> Hello </  <web-resource-name>

              

                 <url-pattern> /banking/teller/* </url-pattern>

        </web-resource-collection>

</security-constraint>

</web-app>

 The above code states that all resources within the /banking/teller directory are protected. It is also important to notice that in the above code that no HTTP methods are specified. When no HTTP methods are specified, all of them are protected from open access (or constrained) This ensures that all methods are protected to access the resources and is an ideal way to ensure web security.

On the other hand, specifying a HTTP method the following way ensures that only the particular method (POST, in this case) is constrained and the other methods are for open access.

<web-app>

   <security-constraint>

      <web-resource-collection>

              <web-resource-name> Hello </  <web-resource-name>

                        <url-pattern> /banking/teller/* </url-pattern>

                          <http-method> POST </http-method>

        </web-resource-collection>

</security-constraint>

</web-app>

The above code states that accessing the resources at /banking/teller is constrained only by the POST method.

 We have extended our discussion of web application in Java by talking about authentication and authorization. We will continue this discussion in subsequent posts.

 

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.

Related Posts

Leave a Comment

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

Scroll to Top