In "Is the security-manager enabled in your server?," Felipe Gaucho points out a subtle problem that can affect your deployment cycle: Java EE servers that enable the security manager. Some containers don't use security by default, and others do, which can create interesting problems when you deploy to production on a secured server.

From the 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.

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 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.

At least Resin people are against using security manager. Here's a quote from Resin documentation :

"Don't use a security manager if you're not in an ISP environment or using RMI. There's no need for it and the security manager does slow the server down somewhat."

If server doe's not download untrusted client code then I see no reasons to use security manager for RMI and I do not think it is a good idea to share JVM in ISP environment or do dpwnload and to run client code on server with or without security manager.

Probably it is usefull for stuff like applets on client side only.

well, the specification claim very clear about the need of the security-manager. Two options:

1) the specification is wrong
2) the implementations as wrong

:))

Enabling the SecurityManager in the app server and configuring it properly does have its advantages. Simple example: your PDF serving servlet would not accidentally serve any other file from the server(yes, I know by now you would have put a complex input filter inorder to prevent this). Effective security should always propagate from core.

Could someone kindly answer:
1. Performance: I think there would be a significant impact. Any thoughts? Has someone tried to quantify this?
2. JAAS authorization: Really needs design to accomodate serverside apps. I lost count of how many frameworks are there to solve the same problem. Thoughts?

This one is bit offtopic:
If you see the security design in Java, the resources protect themselves: For e.g. there is code inside the File class that checks for permissions. The question might be stupid, but let me ask anyway: Can't the JVM take care of this transparently instead of resources protecting itself?

I think OS protects files without problems. JAVA SecurityManager can protect file from JAVA only and it is not secure on server anyway.