Securing Web Applications with Servlet Security:Part-2

In the part-1 of this blog we have the seen the security mechanisms supported by servlet specification 3.0.

Now we will see how to implement those mechanisms declaratively and programmetically,the two common approaches to security.

Declarative Security:means specifing the security requirements in DD(web.xml) of the web application .The requirements include roles, access control, and authentication requirements(see servlet spec 3.0).

By default web resources(servlets, jsps, etc) are accessable to everybody,so to restrict the resources from public access we need to know about 3 things.

i)Web resource collection:tells which resources are to be protected from public access .

            for ex:   <web-resource-collection>
                             <web-resource-name>reports</web-resource-name>

                              <url-pattern>/servlet/SalesReportServlet/\*</url-pattern>

                              <url-pattern>/servlet/FinanceReportServlet/\*</url-pattern>

                              <url-pattern>/servlet/HRReportServlet/\*</url-pattern>

                              <http-method>GET</http-method>

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

                         </web-resource-collection>

The <web-resource-name> is optional and is used to easily identify the security constraint.

                 The <url-pattern> is the resource url which we want to protect.

The <http-method> tells that for which type of requests we have to protect the resources.In the above ex.only GET and POST are   specified .So these two are only constrained , but remaining request types(PUT,TRACE, etc) are not constrained.Thus anybody can access  the above resources freely with out any constraint for the remaining request types(PUT,TRACE, etc).

                 If  no <http-method> is specified ,then the constraint is for all types of requests.

ii) Auth Constraint:tells the roles who can only access the specified web resources

                                    for ex:      <auth-constraint>

                                                                <description>accessible to all supervisors and directors</description>

                                                                <role-name>supervisor</role-name>

                                                                <role-name>director</role-name>

                                                     </auth-constraint>

The <description> tag is optional and it describes about the rolls that access the resources

The <role-name> tag tell that the roles which can only access the resources with specified http requests

                      The <role-name>\*</role-name> tag tells that it includes all the roles defined in the web app are constarined.

                      The absence of  <auth-constraint> indicates that it includes all the roles defined in the web app.

                      The empty tag  <auth-constraint/> indicates that nobody can access the specified resources

iii) User -Data-Constraint:which we have seen in the part-1 of the blog.This helps attackers prevent stealing data while it in the transmission. This process involves the use of SSL to encrypt the traffic between the browser and the server.


The complete sample  web.xml can be

<?xml version="1.1" encoding="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

     <servlet>

          <servlet-name>SecureServlet</servlet-name>

          <servlet-class>com.sur.secure.SecureServlet</servlet-class>

     </servlet>

     <servlet-mapping>

          <servlet-name>SecureServlet</servlet-name>

          <url-pattern>/securelogin</url-pattern>

      </servlet-mapping>     

    <security-constraint>

          <web-resource-collection>

              <web-resource-name>wholesale</web-resource-name>

              <url-pattern>/securelogin</url-pattern>

              <http-method>GET</http-method>

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

         </web-resource-collection>

         <auth-constraint>

              <role-name>Manager</role-name>

         </auth-constraint>

        <user-data-constraint>

             <transport-guarantee>CONFIDENTIAL</transport-guarantee>

        </user-data-constraint>

    </security-constraint>

    <security-constraint>

        <web-resource-collection>

             <web-resource-name>retail</web-resource-name>

                   <url-pattern>/someotherservlet</url-pattern>

                   <http-method>GET</http-method>

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

            </web-resource-collection>

            <auth-constraint>

                   <role-name>Developer</role-name>

             </auth-constraint>

    </security-constraint>

    <login-config>

       <auth-method>FORM</auth-method>

       <form-login-config>

            <form-login-page>/formlogin.html</form-login-page>

             <form-error-page>/formerror.html</form-error-page>

       </form-login-config>

    </login-config>

    <security-role>

      <role-name>Manager</role-name>

      <role-name>Developer</role-name>

    </security-role>

</web-app>

Thus restricting the webresources from public access and allowing only certain roles to access some resources  using declarative security mechanism

With declarative security none of  webresources(servlets/jsps) need to know  security related code

Please note that these protections apply only to direct client access,these does'nt apply to resources which are accessed by means of RequestDispatcher, jsp:forward or jsp:include.

Programmetic Security: With programmatic security, protected servlets and JSP pages at least partially manage their own security. To prevent unauthorized access, each servlet or JSP page must either authenticate the user or verify that the user has been authenticated previously. Even after the servlet or JSP page grants access to a user, it can still customize the results for different individual users or categories of users.

for example, if we want a  servlet to be  accessed by all employees and generate some output for managers and a different output for directors etc,then programmetic security helps here for generating outputs depending on the users roles .

In this mechanism servlet spec. supports 3 methods of HttpServletRequest interface:

1) isUserInRole(): This  method determines if the currently authenticated user belongs to a specified role.If so, this method returns true other wise false.

2) getRemoteUser(): This method returns the login name of the current authenticated user,returns nulll if the user is not authenticated.

3) getUserPrincipal(): This method returns a java.security.Principal   object containing the name of the current authenticated    user. It returns null if the user is not authenticated. Calling the getName() method on the Principal returned by getUserPrincipal
returns the name of the remote user.If the user is not authenticated  getUserPrincipal() method returns null.

                     The reason for using this method is ....

The following sample demonstarates the usages of above methods :

public void doPost(HttpServletRequest req,
                   HttpServletResponse res)
                   throws IOException
   {   PrintWriter pw = res.getWriter();
        pw.println("<html><head>");
        pw.println("<title>Programatic Security Example</title>");
        pw.println("</head>");
        pw.println("<body>");
       String username = req.getRemoteUser();
------------------------->>gets the username
       if(username != null)
          pw.println("<h4>Welcome, "+username+"!</h4>");
       if(req.isUserInRole("director"))------------------->>
determines if the user is a manager
       {  pw.println("<b>Director's Page!</b>");
       } else {
          pw.println("<b>Employee's Page!</b>");
       }
      pw.println("</body></html>");
}





Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Suresh Mandalapu

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today