Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript 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

Some brain-storming questions in security

 
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am having some doubts after reading the security chapter in HFSJ. Mostly, I feel the book does not have a clear answer for these. Please see if you can answer these :

1. If there are two conflicting <security-constraint> elements for the same resource :

<security-constraint>
<web-resource-collection>
<web-resource-name>Sample1</web-resource-name>
<url-pattern>/Beer/UpdateRecipes/*</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>

<security-constraint>
<web-resource-collection>
<web-resource-name>Sample2</web-resource-name>
<url-pattern>/Beer/UpdateRecipes/*</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>

Which security-constraint wins? Does everybody have access to POST on UpdateRecipes or nobody? The book says that <role-name>*</role-name> combines with anything to give access to everybody. It also says that <auth-constraint/> combines with anything to give access to nobody and that <auth-constraint/> has the final word. What happens when these 2 meet? This is not clear from the book

2. How to constrain JSPs?

<security-constraint>
<web-resource-collection>
<web-resource-name>Sample</web-resource-name>
<url-pattern>/Beer/BeerTest/beer.jsp</url-pattern>
</web-resource-collection>
<auth-constraint/>
</security-constraint>

Would this constrain the beer.jsp? In this case, /Beer/BeerTest/beer.jsp would be an actual physical path and not a logical path as in the previous servlet example. And if this works, it would have exactly the same effect as putting the beer.jsp under WEB-INF. Am I right?


3. <security-constraint>
<web-resource-collection>
<web-resource-name>Sample</web-resource-name>
<url-pattern>/Beer/BeerTest/*</url-pattern>
</web-resource-collection>
<auth-constraint/>
</security-constraint>


Lets assume that there is a REAL PHYSICAL directory structure - /Beer/BeerTest containing some JSPs. Also say, there is a servlet declared in the DD that matches this logical url-pattern. In this case, the above DD declaration would constrain the JSPs under the physical directory or the servlet matching the logical url-pattern or both??? What will be the answer if I had included a <http-method>?


4. The book says - "If there is an auth-contraint declared in security-constraint, it must authenticate access to the URL's in the url-pattern and if there is NO auth-constraint in security-constraint, it must allow un-authenticated access to the URL's specified in url-pattern".

So I understand that :

<security-constraint>
<web-resource-collection>
<web-resource-name>Sample</web-resource-name>
<url-pattern>/Beer/BeerTest/*</url-pattern>
</web-resource-collection>

</security-constraint>

must allow unauthenticated access to the resources specified by the <url-pattern>.

But what about this ?

<security-constraint>
<web-resource-collection>
<web-resource-name>Sample</web-resource-name>
<url-pattern>/Beer/BeerTest/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>

Will this allow unauthenticated access to the resources in BeerTest or will it authenticate every user before accessing the resource (because auth-constraint IS there), even though all users are allowed to access the resource?


5. Can I use <transport-guarantee>CONFIDENTIAL</transport-guarantee> with BASIC, DIGEST and CLIENT-CERT authentication methods? Or can it be used only with FORM-based authentication? I feel it can be used only with FORM because the other methods have their own way of transmitting the data (encoding, encryption, PKC), but I am not very sure.

Thanks in advance for your answers.
 
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) Don't know. I think, you can test it yourself, and post the answer
2) In this case, logical path will be the same, as physical path, and you will constrain the beer.jsp, indeed. Note: you can define a servlet, mapped to JSP file, and then define a new path to you jsp in servlet-mapping.
3) This security-constraint will constrain both, servlet and jsp. http-method has no impact on the answer (except constraining only calls, made with this method)
4) If you define auth-constraint, the the user must be authentificated, before accessing this resource. And user's role must be one, of the defined in the DD. If you have no auth-constraint, than user can be unauthentificated at all
5) I think, you can use BASIC, FORM and DIGEST authentification methods with CONFIDENTIAL transport-guarantee. And possibly CLIENT_CERT too. Because authentification methods is a method to authentificate a user, and transport-guarantee is a method to transport data betwen client and server.
 
We should throw him a surprise party. It will cheer him up. We can use this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic