Skip to main content

Is the security-manager enabled in your server?

Posted by felipegaucho on January 4, 2006 at 5:37 PM EST

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.

fishing.gif

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:

Related Topics >>
Blog Links >>

Comments

Very good

by joellobo - 2010-01-29 14:39

Some basic concepts are ignored by some developers