This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of AWS Security and have Dylan Shields on-line!
See this thread for details.
Win a copy of AWS Security this week in the Cloud/Virtualization 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
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

No <auth-constraint> and <role-name>*</role-name>

 
Ranch Foreman
Posts: 1906
13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On p.669 of Head First,


<security-constraint>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>



has the same effect as

if there is no <auth-constraint>



But on p. 623 and p. 628 of Charles Lyon's book:

The only way to allow all users (even unauthenticated users) through is to not declare any elements; declaring a <role-name>*</role-name> is equivalent to allowing any authenticated user to access the resource.



Which book is the right explanation?
 
Ranch Hand
Posts: 62
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Himai,

The two books are saying the same thing.

In Head First, the two configurations have the same effect but the user must always be authenticated because the <security-constraint> is never removed.

In the Lyon's book, the unauthenticated users have access to the application only if ALL security elements are removed: <security-constraint> and <auth-constraint>

Best regards,
Marcos.
 
Creator of Enthuware JWS+ V6
Posts: 3346
303
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Marcos R Oliveira wrote:In Head First, the two configurations have the same effect but the user must always be authenticated because the <security-constraint> is never removed.


It is a bit more subtle: having an <auth-constraint> requires the container to authenticate the user. After authentication the user is allowed to access the secured resource no matter what role he has. If there is no <auth-constraint> declared in a <security-constraint> then the container must accept the request without requiring the user to be authenticated.

The effect of the two configurations is almost the same however unauthenticated users are only allowed in the latter.
 
New rule: no elephants at the chess tournament. Tiny ads are still okay.
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic