In one of my previous posts, I described how to create a custom policy file for one's application. The process was manual and incremental. Because of that, it was painstakingly long, and hence not really useful. Since I wrote the post, I found a way to write the policy file under in a couple of hours, instead of days.
If you already had to manage some degree of randomness on Java, chances are you got acquainted with the Math.random() methods. However, the previous method returns a double. Beyond very basic use-cases, another option has to be considered, in the form of the java.util.Random class. Random An instance of this class is used to gener
I’ve already written about the JVM security manager, and why it should be used - despite it being rarely the case, if ever. However, just advocating for it won’t change the harsh reality unless some guidelines are provided to do so. This post has the ambition to be the basis of such guidelines. As a remin
Java makes it possible to compile Java code at runtime… any Java code. The entry-point to the compilation is the ToolProvider class. From its Javadoc: Provides methods for locating tool providers, for example, providers of compilers. This class complements the functionality of ServiceLoader. This class
This week, I wanted to make a simple experiment. For sure, all applications we develop make use of HTTPS to encrypt the login/password but what happens before? Let’s say I typed my login/password but before sending them, I’m called by my colleague and I leave my computer open. My password is protected by the HTML password input, right? It shows stars instead of the real characters. Well, it’s stupidly easy to circu
For sure, software security should be part of every developer’s requirements: they should be explained and detailed before development. Unfortunately, it happens in real life that this is not always the case. Alternatively, even when it is, developers make mistakes and/or have to make with tight (read impossible) plannings. In the absence of security checks automated tools, sooner or later, an issue will appear.
I’ve been thinking about having a more secure password management since ages. At first, my only concern was to share my bookmarks and history between my different computers (at that time, phones were conveniently left out of my scope). Since Firefox was my browser of choice, I decided to go for Foxmarks (now called XMarks and available for more browsers). However, it soon became apparent that my natural lazyness came back and
My debugging contest of the week happened to take place on a IBM AIX system. The bug happened when we upgraded from Java version 1.4 to version 6 (which I admit is a pretty big step). Suddenly, an old application stopped working and its log displayed NoSuchAlgorithmException. A bit of context: when Java applications have to connect to hosts with SSL over HTTP, they must trust the host - it’s the same as when you b
One thing I'm doing very often and always searching on the Internet is how to obtain a self-signed SSL certificate and install it in both my client browsers and my local Tomcat. Sure enough there are enough resources available online, but since it's a bore to go looking for the right one (yes, some do not work), I figured let's do it right once and document it so that it will always be there.
Servlet 3.0 is not only about the replacement of the web.xml deployment descriptor by annotations. In this article, we’ll see what improvement it makes in the realm of security. In Servlet 2.5 (and before that), declarative security was about the following features: authentication method (BASIC, FORM, etc)authorization to differents parts of the app
My work is IT architecture, meaning I focus on the early steps of a project. Once the application is in production, I usually leave it to systems and production engineers. For example, for JVM fine tuning, most of the clients I worked for have people that have the right skills to do that. Nevertheless, I need sometimes to sully my nails. This happens in two cases: when the client is too small to have such dedicated teams or when its
Tomcat manages application security through the concept of realm. A realm is a coherent package of name password pairs that identify valid users for a web application. Tomcat’s default realm is MemoryRealm. This realm reads the famous conf/tomcat-users.xml file and uses it check for name password pair validity. Tomcat also provides realms to check against pairs stored in a database, either through a direct connect