Felipe Gaucho's Blog: January 2006 Archive

In my new occupation as independent consultant I have visited several companies that produce web applications. Same products, same bugs, including a classical one: the char encoding problem.

Using Brazilian Portuguese as default language, many of these companies release international software developed by teams with different levels of expertise. Most of these people are skilled in the internationalization aspects, such as Date formats, TimeZone settings and characters handling. Other ones simply bet on the IDEs in order to guarantee the correct Content-Type.

It's an old issue on software published on the Internet, but it seems that the new developers are not worried about that anymore. I guess it is time to review some basic concepts about that.

Following suggestions of friends, I found this very good article in the Joel on Software:

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) by Joel Spolsky - Wednesday, October 08, 2003

The date of the article give us a clue about how long it has been haunting the web development :).

let's do it again, using GregorianCalendar

Posted by felipegaucho on January 11, 2006 at 07:36 AM | Permalink | Comments (7)

Few days ago I was listening a client about the framework his company was producing for a long time. Tips about the workflow, security and several other common features of a framework. A special feature gave me a déjà vu: the control of holidays in the financial modules. Every financial calculus is based on working days and every framework I've ever seen in my life had also a module for the calculation of workdays range - subtracting holidays, sundays, etc.

These modules are so identical that I've started to think about the need to include that feature in the java.util.GregorianCalendar or some other implementation of the Calendar Interface.

I know APIs should avoid features from specific applications, such as it was well explained in a recent entry of the Eamonn McManus blog. But this special algorithm - the calculus of workdays within a time interval - is so common that I think it should be included as a generic feature in a next review of the class GregorianCalendar.

Everyone who already implemented such feature knows about its functionality: you store a list of holidays, and the Calendar identify the Sundays for you. The algorithm consists in comparing each day of the time interval with the days from that holidays list. Quite simple, but quite repetitive for all system implementation.

One can argue that companies can implement it just once and reuse the algorithm in the new systems. I agree with that, but I also think such obvious algorithm should be part of the Java API as a facility.

I was thinking about a Java Specification Request or just suggest this new feature to the JDK community, but I prefer to listen you first. I'm not sure if there is something already supported by the API (I didn´t find any reference about that) and I also prefer to discuss its utility with you before to go into the formal aspects of a specification request - a sanity check :).

Is the security-manager enabled in your server?

Posted by felipegaucho on January 04, 2006 at 02:37 PM | Permalink | Comments (4)

Recently I have tried to run Cejug-Classifieds on GlassFish - my first try was frustrated because the application didn't open even the first page. And the server console didn't reflect anything about the problem. Very strange, but very didactic also, as I will explain in this blog entry.

Cejug-Classifieds assume Tomcat as its target server and it also was tested on Geronimo and Websphere. Due to these successful tests, I got confused about such a difficulty to run it on GlassFish. After few inspections and with a very helpful support from the GlassFish forum, I figured out the problem: security-manager issues. Glassfish comes with the security-manager enabled by default and it avoided my application to include security restrictions on demand - my original algorithm. The Cejug-Classifieds has a security module based on a JassFilter designed to authenticate user requests. During the JaasFilter instantiation, the system adds a set of file names into the system properties.

On the code below copied from the login module, the method init(FilterConfig) of the filter tries to set the name of the JAAS^* properties files as System properties, but it is not allowed when the security-manager is enabled:

	public void init(FilterConfig arg0) throws ServletException {
		ServletContext context = arg0.getServletContext();
		System.setProperty("java.security.manager", "");
		System.setProperty("java.security.policy", context
				.getRealPath("WEB-INF/jaas/default.policy"));
		System.setProperty("java.security.auth.policy", context
				.getRealPath("WEB-INF/jaas/app.policy"));
		System.setProperty("java.security.auth.login.config", context
				.getRealPath("WEB-INF/jaas/jaas.config"));
	}

* JAAS is a subject to a further blog entry - for now, I will focus on the security-manager.

The work around this problem and the discussions about security revealed a curiosity: the most popular web-servers come with the security-manager disabled. Why? The server vendors argue about the facility of disabling security-manager during the development phase and also argue about the need of a experienced technician in order to configure the correct details during the deployment into a production server. Well, I agree in part with such policy but I perceive the damage on the culture of the developers. How many times did you, developer, think about the security-manager and its functionality? If you answer almost never or if you even don't know what this thing means, don't worry - you are part of the majority of Java community that never has time or interest to learn about that.

Another interesting detail is about the Java^TM 2 Platform Enterprise Edition Specification, v1.4 which claims that the Security Manager is not optional; it must be enabled in the Application Server. Glassfish just follows the specification - and why the other servers don´t do the same? The answer seems related to the legacy software - several years of unsafe servers have given us a comfortable feeling about the servers with security-manager disabled. Your server is probably running without security-manager right now, and I invite you to think about such fragility.

What is the security-manager about?

By the specification: The security manager is a class that allows applications to implement a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed. The application can allow or disallow the operation. In simple words: imagine a client deploying a new application in the server of your company. How can you verify if this application is not hacking your system, injecting data in your server or facilitating a hacker attack? The most common answer is: my server administrator will take care about that. The second question is about how the administrator will guarantee the server safety if he doesn´t have access to the application code. Everything depends on the confidence between you and the application owner - a fragile policy, isn´t it?. The evaluation of how the software is produced and also the deployment procedures reveal the main issue: the most part of developers doesn´t even know about security needs in a web-application software. They ignores the problems a malicious code can produce in a server because the majority of the servers never forced them to think about that. I have been observing a lazy behaviour in terms of security - the application running on the server seems to be the only objective of the developers and the security consists on a low priority concern.

The most part of developers ignores the security needs in a web-application software.

The absence of a security-manager causes a lack of knowledge about the security concepts underneath the JAAS framework - and that was the main problem with my simple web-application. Talking with friends I detected that this problem is much more common than I was expecting and then I decided to write about it. Asking about security-manager, experienced developers revealed weird concepts about that, including something you need to disable in order to get all the things working on. That indifference about security seems to be a flaw in the development process - and also a dangerous culture.

I think if you expose your developers to a safe environment since the beginning of your next project, there is a better chance it will be conformant with the servers with security-manager enabled. Better yet, if you spread the security concerns in your institution, there is a great chance of offering more elegant products for your clients - more safety, more software quality.

The game of the roles - a way to learn JAAS.

Security-manager provides security to the server, but your developers are not system administrators - how to teach them about security? How to provide a real JAAS experience for your team? The applications I have done in the last few years had no security - it was traditional Java web-applications based on simple login/password authentication, most of them without JAAS - just simple verification through databases or files. When I started to use JAAS, a more sophisticated development become necessary. Through JAAS you can't simply use if(...) statements in order to verify if a user can execute a procedure into a system, you need to delegate the validation to the web-container and that is more complicated, however more elegant. In order to improve the security of my applications, I adopted the following policy: nobody can access my application without a role. If I have a funcionality open for all users, then I adopt a guest role in order to allow anyone to use that. The pratice with roles and the learning required in order to deal with the JAAS configuration files have enhanced my view about how the things work on the J2EE world - and I strongly recommend you to include JAAS in your development cycle.

Acknowledgments: I would like to register the friendly support from the glassfish team - Jean François Arcand and Ronald Monzillo demonstrated patience and gave me an excellent way to learn about glassfish. The glassfish team seems very motivated and I guess their Java EE 5 Application Server will rock on 2006. The cejug-classifieds team is hard working in the first release of our project - and we will try to distribute a pre-configured package to run on glassfish.

References:

Powered by
Movable Type 3.01D

java.net RSS Feeds