This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Five Lines of Code and have Christian Clausen on-line!
See this thread for details.
Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

auth-constraint confusion

 
Ranch Hand
Posts: 300
Eclipse IDE Oracle Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers,
I have a doubt in <security-constraint> element of web.xml which includes <auth-constraint> .It is said that if <auth-constraint></auth-constraint> and <auth-constarint><role-name>user</role-name></auth-constraint> are defined for one particular component then no one get access to that component.But i want to know whats the result of defining <auth-constraint><auth-constarint> and <auth-constraint>*</auth-constarint> for a particular component,which one have the high priority,wether everyone gets the access or no one will get the access?




Knowledge Spreads Everywhere!
ruquia.
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, note that <auth-constraint> needs a sub-element <role-name> if it is not empty (e.g., <auth-constraint>*</auth-constraint> is not valid in the dd). Typical trip-up question for the exam!

Also, it is important to realize that a security-constraint protects a url-pattern, not a component. I know this, because it was a gotcha on one of the practice exams in Bridgewater's book, that fooled me.

Try the following example:
  • Create a web-app with only an index.jsp page (for instance with NetBeans)
  • Overwrite the contents of web.xml with the version below. I am assuming that you have a user ide with role admin and password admin (standard in NetBeans); if you don't have them, create them (in Tomcat: edit tomcat-users.xml).
  • Deploy and run the web-app.
  • You'll get a 403 error
  • Now enter a path of /Backdoor (with the context-path in front, of course, e.g., http://localhost:8084/SecurityTest/Backdoor)


  • If everything goes well, you'll get a pop-up that requests a user name and password (BASIC authentication). Any user that has a role declared in web.xml will do (if he enters the correct password for his account).

    This demonstrates that: 1) The security-constraint protects a url-pattern (because both All-denied and All-access-for-backdoor security constraints essentially protect the same jsp), 2) that auth-constraint for role-name=* means that all declared roles have access and 3) auth-constraint without body has precedence over one with body.

     
    Ranch Hand
    Posts: 893
    Tomcat Server Java Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    An empty <auth-constraint> tag combines with anything and has always the final word. This means no-one has access.

    If you're using HFSJ it's on page 639
      Bookmark Topic Watch Topic
    • New Topic