• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Webapp-Security chapter revision notes from HFSJ , may be useful

Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chapter : 9 : Security in webapps.

1) We are concerened about four things in terms of security :
a) Authentication
b) Authorization
c) Data integrity
d) Confidentiality

2) We will discuss below tags for security :
a) For authentication we use : (Remeber word login for this .)

When we use any of these in our DD , client will be sent login screen to enter their username and password except in FORM way , where customised login and error forms are used writen by us.

During the authentication , the username and password is matched with the enteries in tomcat-users.xml present under web-app/config directory or enteries may be in some other table used for this or enteries may be in LDAP system.

But we are interrested in way the tomcat-users.xml is written , the format of it:

Fron tomcat-users.xml : This will be used while authenticating .
<tomcat-users> [ role and user two main elements]
<role rolename = “Admin” />
<role rolename = “Guest” />
<role rolename= “Member” />
<user username=”vishal” password=”code” roles=”Admin, Member, Guest” />
<user username=”Mohit” password=”decode” roles=”Admin,Member”/>
<user username=”Anuj” password=”victory” roles=”Guest” />


From web.xml:
Under <web-app>
<auth-method>BASIC</auth-method> [ uses Encoding , weak , HTTP supported]


<auth-method>DIGEST</auth-method> [ uses Encryption , strong , HTTP supported , all container do not support it , less used]

<auth-method>CLIENT_CERT</auth-method> [Strong , clients must have PKC, J2EE supported]

<auth-method>FORM</auth-method> [Very weak , no encryption , J2EE supported]

Here I wanna practice like how to write customized login and error page as below:

1)loginPage.html :

<form method=”POST” action=”j_security_check”>
<input type=”text” name=”j_username” />
<input type=”password” name=”j_password” />
<input type=”submit” value=”Enter” />

2)errorPage.html :

<html> <body>
Sorry dude, wrong password.
</body> </html>

b)For authorization and data integrity we use :
Authrization is for maintaining access to the constarined resources by using constrained methods by constarined roles.
( For this remmeber the word “security” of web-app , under it we take care of )

 <security-constraint> will come directly under <web-app> directly
 Very Important : We can have >1 security constraint in DD

For authorization : <security-role > element must also be there in DD as below which will do mapping between the roles in realm to roles in DD. Its declared as below :

<role-name>Admin</role-name> [ see here (and in <auth-consta we have role-name and in realm we had rolename]

<web-resource-name>UpdateRecipes </web-resource-name> [Mandatory]


<auth-constarint >
< role-name>ADMIN/MEMBER/GUEST/*< /role-name>
</auth-constarint >



While using <security-constraint> , in this element , using <http-method> and <auth-constraint> is optional and some hard rules as below , and I have digested them  as below:

 If there is no <http-method> element used , then No HTTP methods are allowed by any user.
 If there is method specified , then that specified method is constarined and that method can be invoked by roles authorised by <auth-constraint> to access the constrained resourse , the methods not specified are not constrained and can be invoked by any role.
If there is no <auth-constraint> element , that means all roles are allowed to make access.
If there is empty <auth-constarint> element , that means all roles are constarined , no role can access constrained resource using constrained method.
If roles are specified then only those roles will be able to access the constrained resource using the constarined method.

 If the resource requested is constarined then only container bothers for authentication and achieve this by sending status code: 401 , www-authenticate header with realm info.After this browser makes another request sending the username and password with a security HTTP header and now the container matches the username and password , if they match , then it asks for authorization that is it checks if the user is assigned to role and that role has access to constrained resource , if it succeeds then access is granted to constrained resource.

Servlet developer – writes servlet
Application admin – decides and writes roles in tomcat-users.xml
Deployer – which servlets should be protected and which roles will have access to them

Programeatic security :

if (request.isUserInRole(“Manager”) )
{ }

[Our company uses Admin instead of Manager , but we don’t want to change the every occuranve of this as then we have to recompile the whole servlet code which we don’t want.]
If the developer uses above programatic security, he has to use <security-role-ref> also to map his hardcoded roles to existing roles in <security-role> element as below.PLEASE NOTE THAT THIS <security-role-ref> is under <servlet> element .Yes the servlet code in which this programatic security is used up.

<web-app> [Manpping from Manager to Admin]


when we tell the container that we want to implement the data int. and confidentiality , we use <user-data-constraint> element in the DD , then J2EE guarantees that data will travel over the “protected transport layer “ . Protocol used will be changed from http to https over SSL (Secure Sockets ) layer.
In this case , if the container recieves the request for constarined resource and if for this resource the <transport-gurantee> element is present then container responds with 301 status code and sends the Location header in response , then browser makes request again for the same resource but now over a secure connection using the protocol https ,
Now when the container sees that the request for constrained resource , it send the 401 status code and ask for authentication (yes broweser have to request for third time ), then client sends the username and password then it does authentication and authorization . Please note here username and password are traveling securely.
Reember https occurs over SSL always.
Don't count your weasels before they've popped. And now for a mulberry bush related tiny ad:
a bit of art, as a gift, that will fit in a stocking
    Bookmark Topic Watch Topic
  • New Topic