Talk:Declarative Access Control in Java

Status

Under review

Authors

• Dave Ferguson

Reviewers

• Pierre Parrend

General Discussion

• global comment: this overview is very quick, but clear and efficient

• Introduction: a remainder of the technical context could be useful - what piece of code do one needs for executing this declarative access control: a servlet container ? a J2EE platform ?

DFerguson - I added some verbiage about JEE-compliant application servers.

• first XML excerpt: no global tag is shown. If I have a real Web App descriptor without security, in which tag should I put the given xml code ?

DFerguson - I added the web-xml root tag before and after the snippet. There is also a link to the servlet spec in the Overview section now, which is for readers who want to see the deployment descriptor in detail.

• authentication methods 'Digest' ad 'Client cert' are evoked. How can they be implemented, i.e what is required on the client side (algorithm, certificate with proper issuer) and on the server side (algorithm for digest and certificate control, access to a trusted certificate database)

DFerguson - This is not my area of expertise, so I would need more time to research, or I would accept help from someone else of course.

• 2 different 'transport guarantees' are evoked, 'integral' and 'confidential'. What specific protocols, algorithms, and data, are required ?

DFerguson - My understanding is that Integral and Confidential causes the container simply enforces SSL communication. I would need more time to research to supplement what is already there.

• SSL is evoked. a pointer toward a SSL page could be useful

DFerguson - I added a link to the OWASP SSL page, but it is just a stub and not very helpful. Any other suggestions where the link should point to?

• no extra link is given. Is it deliberate from the Owasp editor ? Where can I go and look if I need further information ?

DFerguson - other than reference material in the servlet specification and various application server documentation, I don't know where more information is available. That's one of the reasons I thought this page would be helpful. Please let me know about anything that I might be missing.

• I usually recommend storing the JSP files used for form based authentication in the WEB-INF directory. This way they cannot be accessed directly from the browser

DFerguson - I don't understand why that would improve security. What threat is mitigated by having the JSPs inaccessible from the browser?

Jeff Williams - This is really critical to understand. In some applications, the JSPs are intended to be accessed directly, and they contain some business logic and some presentation layer. But in most modern frameworks, there is a controller servlet that handles all the http request, invokes business logic, and forwards the request to the appropriate JSP. The JSP relies on information in the request or session attributes to be properly set. If you invoke the JSP directly, you are likely to get null pointer exceptions (because the attributes aren't there). But many times you can figure out what parameters the JSP code is expecting and you can make it do something. And occasionally, what you can force it to do is unauthorized and very damaging.

DFerguson - Agreed, but if you know what you're doing you can prevent that from happening, such as having an include at the top of every JSP to check that the session state is valid. I guess the key is that developers have to understand the issue. I don't necessarily agree with an absolute rule about not accessing JSPs directly. As we know a JSP is really just a servlet. If you access a controller servlet directly, you can take steps to be able to safely access a JSP directly. If you're using a framework where that is out of the ordinary, then certainly I would not do it. I doubt someone using a framework would be using declarative access control anyway.