• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question about authentication mechanisms

 
mohamed ewis
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi , all

What is true about Java EE authentication mechanisms?

1- If your deployment descriptor correctly declares an authentication type of CLIENT_CERT, your users must have a certificate from an official source before they can use your application.

2 - If your deployment descriptor correctly declares an authentication type of BASIC, the container automatically requests a user name and password whenever a user starts a new session.

3 - If you want your web application to support the widest possible array of browsers, and you want to perform authentication, the best choice of Java EE authentication mechanisms is DIGEST.

4 - To use Java EE FORM authentication, you must declare two HTML files in your deployment descriptor, and you must use a predefined action in the HTML file that handles your user's login.

why answer #4 only is the correct answer
i think answer #1 is also correct
is that true
 
Dee Brown
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Security is not my strong point (I even leave my front door unlocked). However, it is possible that answer 1 is not correct because certificates can be obtained from non-official sources, and I believe there is such a thing as a self-signed certificate. I seem to recall receiving 'not trusted' certificate warnings, which likely indicates the certificate is not from an official source.
 
Antonio Tercero
Ranch Hand
Posts: 110
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Answer 1 is not correct because you can create your own client certificate signed by your own Certificate Authority.
For example, using openssl, you can create all kind of certificates.
 
Charles Lyons
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Technically all of those are wrong:

1. As mentioned above, your users need an SSL certificate but this can be a self-signed one, though that covers very dodgy ground which I very much doubt would be asked on the exam.

2. You would also need to declare the security-constraints for a set of resources: just having the type of auth declared is insufficient.

3. BASIC is the most widely supported; DIGEST is optional (though still almost universally supported these days)

4. "you must declare two HTML files" is at best misleading. In fact you must specify two context-relative paths (which may be identical but must each begin with a /) for the login and error pages. These don't need to be HTML files - they could be servlets, JSPs, PHPs or anything else which generates a valid response in the browser. This should really read: "To use FORM authentication, you must declare two context-relative paths in your deployment descriptor, and you must use a predefined action in the HTML form that handles your user's login.". A bit nit-picky, but accuracy is always important.
 
Dee Brown
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since the references in the spec that I was able to locate state that form-login/error-page are the location of pages, I am not sure if either of these can be a servlet. Furthermore, the action (i.e. j_security_check) and field restrictions on the form would seem to imply that it is not a servlet.
 
Charles Lyons
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are correct about the fact the path is to a physical page-type resource - my oversight. But in my defence this resource can be a JSP (I have used this often myself) and a JSP is compiled into a servlet. So in essence it can forward to a servlet! The way it effectively works behind the scenes (though the exact details are container-dependent) is the container forwards the rendering over to the page you specify, in a similar way to using a RequestDispatcher forward invocation. So there's no reason the login/error pages can't be a servlet, except for the deployment descriptor restriction on the path format.
Furthermore, the action (i.e. j_security_check) and field restrictions on the form would seem to imply that it is not a servlet.
I don't see how that follows. The action is just recognised by the container as a special code to invoke the container's own authentication mechanism rather than one of your own resources - it doesn't matter if the login page was generated by a servlet (or JSP!) or a static page. It also doesn't matter if the page is HTML or otherwise, provided it supplies the correct HTTP POST form data.
[ June 23, 2008: Message edited by: Charles Lyons ]
 
Dee Brown
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So in essence it can forward to a servlet!


Although I am concerned with actual application of the spec, I am also concerned with what would be considered correct when taking the exam since that is what many of us are here for. I would not suggest that a resource can be a servlet when the spec consistently states it is a page because to do so could result in someone getting at least one question wrong on the exam.
 
Charles Lyons
Author
Ranch Hand
Posts: 836
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My comment was meant to be a light-hearted, hence the smiley.

I think my assessment of the topic is fair as far as the exam is concerned. The original question is misleading on face value: the resource it points to can be a JSP page or document and not just a (static) HTML page. That too could catch you out if you thought it had to be a static resource and they give an example using a JSP page which you then answer incorrectly. In practise it is more common to use a JSP as a login page in order that it can fit with the design of your site using, for example, the Composite View design pattern.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic