I found a question on-line that asked "What are the benefits of container-managed security?". One of the options was "Makes an application more portable". I chose this option because it reduces the need to hard-code security logic into servlets and provides mappings for role names if this is really necessary.
The answer said that this was incorrect saying that "only certain features listed in the specification must be implemented by containers". Which features is it talking about?
I think the more interesting question is "what is needed that is not standardized?" The servlet spec does not say how a container gets to know which users/roles there are. E.g., Tomcat has the concept of realms, which get configured in the server.xml file, and which tell Tomcat where (and how) to look for user information. Other servers have similar, but different, mechanisms.
So it would actually be more container-independent to use programmatic security, which could load that user information from a file in the web app, and thus be completely portable between servers. This has of course many practical drawbacks, which would rule this out for most production settings.
posted 13 years ago
I think you've hit the point. If you code a custom solution your web-app will have all the code it needs to implement the app's security if it is moved to a different container.
However, if you use the Container Security you will inevitably have to use container-specific security configuration features of your web container. For example, in Tomcat, you would put entries in "tomcat-users.xml". This would not be directly portable if you moved your app to JBoss.