|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 14
Messages: 14
Messages: 14
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Security Managers: do you use them? For what?
One of the features of Java from early in its design was its security model. Originally, it applied to applets, by isolating them into a sandbox, one that's generally been successful. However, with J2EE and JINI, the security manager constrains programmers from doing unsafe actions - occasionally, actions one needs.
For example, in J2EE, the security manager prevents JSP authors from putting in code such as <% System.exit() %>. (This could be avoided by using a template language instead of JSP, of course, but that doesn't prevent someone from putting the same code in a managed bean or some other class in the application.) It also might potentially enforce other rules in J2EE, by preventing EJBs from spawning threads, or preventing a web application from installing a new SecurityManager.
Security managers are sometimes very annoying in development, so annoying that Glassfish - the Java EE reference implementation - actually turned off the security manager by default.
While turning off the security manager makes using servers much easier during development, migrating the applications into a production environment - where security is likely to still be enabled - becomes very difficult.
For example, using JavaSpaces in a JavaEE application requires installation of an RMISecurityManager, which involves adding ten or more security permissions, each of which has to be determined by examining a failure. JavaSpaces is a rare specific example, but consider that many other libraries require classloader modifications, all of which are illegal under the normal security settings for JavaEE.
Some installations get around this by explicitly turning off the security manager in production.
Is the security manager a factor in your application development? Which servers have you deployed to that enable the security manager? What issues did you find through this, if any, and how did you work around them? Do you think simple removal of the security manager is an acceptable workaround?
|
|
|
Message #216544
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
No, I do not use security managers. It's a pain in the ass to use them. I never ever had any need for the use of them either. Security can be implemented on different levels and methods. You can even build them into the work process.
I never even build an application that uses a application server (even though I consider myself an enterprise developer). If I would build one I would simply demand full control of the application server and that it is only used by our application. This means that security can be switched off, all beans can do anything. Since my company is the only one that inserts new beans I know I can trust them.
Security is ofcourse a important factor of our development process but because of cost and time we often shift the security risc to another party. For instance we create an application and demand a new dedicated computer for it on a firewalled network that is secured by another party.
Still I know it is never secure enough: If the client wants more security he can have it: it just means that the application becomes more expensive.
|
|
|
Message #216546
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
...
Security managers are sometimes very annoying in development, so annoying that Glassfish - the Java EE reference implementation - actually turned off the security manager by default.
While turning off the security manager makes using servers much easier during development, migrating the applications into a production environment - where security is likely to still be enabled - becomes very difficult.
For example, using JavaSpaces in a JavaEE application requires installation of an RMISecurityManager, which involves adding ten or more security permissions, each of which has to be determined by examining a failure. JavaSpaces is a rare specific example, but consider that many other libraries require classloader modifications, all of which are illegal under the normal security settings for JavaEE.
So, just as a note, Jini 2.1 provides a class which can be used to determine all policy requirements in one run saving all that pain. Of course, your container/server needs to support installation of said class and I'm sure some of them will prevent that.
Some installations get around this by explicitly turning off the security manager in production.
Is the security manager a factor in your application development? Which servers have you deployed to that enable the security manager? What issues did you find through this, if any, and how did you work around them? Do you think simple removal of the security manager is an acceptable workaround?
I've certainly settled for removal in the past but personally, I prefer having control over security manager and policy. That's what I get when I work without a container, why not with?
In respect of classloaders, many specs prescribe certain fixed arrangements for classloaders which makes handling downloadable code (as in the case of Jini) difficult. There are workarounds but, really, I'd say specs and containers should also be more flexible in this area.
I guess I'm basically saying that, right now most containers/servers seem to enforce fixed policies where I'd prefer a sensible default with options for me to change things around should I require it.
As it happens, I have had positive feedback from one Blitz JavaSpaces user recently which suggests GlassFish is pretty flexible in this area.
|
|
|
Message #216547
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
Forgot to say, I use a security manager with Jini Services all the time simply because it's an essential (but small) part of providing a secure deployment.
Those I write/deploy such services for take security quite seriously and do indeed want strict control over permissions granted to code/users of code. Sometimes they want control down to individual methods of a given Jini Service.
The real problem with security is that it's aspect like. It touches everything such that if you have one break in the security chain your entire effort is compromised.
|
|
|
Message #216549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
I have not heard of a vulnerability that required configuring other than default security policies. Ted Neward in Effective Enterprise Java suggests turning on "platform security" (Item 62) should an attacker be able to edit and run JSPs. I just have not heard of this happening. I suppose the NSA uses it. Crap! this post is going in my file now.
|
|
|
Message #216553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
Different requirements => different solutions.
If an application server is running only one
application (in a wide sense of the word - not necesarry
only one ear), then security manager is not so usefull.
If an application server is running multiple applications,
then it may suddenly be important that one application
can not do something bad to the server. The most extreme
case is ofcourse web hotels with shared servers.
As long as someone uses them, then we need support
for them.
And BTW Java applet will always need them I guess.
|
|
|
Message #216555
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
Different requirements => different solutions.
If an application server is running only one
application (in a wide sense of the word - not necesarry
only one ear), then security manager is not so usefull.
If an application server is running multiple applications,
then it may suddenly be important that one application
can not do something bad to the server. The most extreme
case is ofcourse web hotels with shared servers.
As long as someone uses them, then we need support
for them.
And BTW Java applet will always need them I guess.
More generally, it's downloadable code (of which Applets are one example) that requires the presence of a security manager. If you can secure all sources of downloaded code and you trust them, you only need the security manager present to enable downloaded code and could set a policy of AllPermission.
|
|
|
Message #216578
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
When the codes running on your computer is not written by you, a SecurityManager is certainly needed. This includes applets on clients' machines and server apps running on an ASP's server written by its customers.
On the other hand, you should never be too confident on your own codes, since they have bugs and will be exploited to do harm on you one day. Therefore, it looks like SecurityManager is always a good thing.
|
|
|
Message #216581
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
I never even build an application that uses a application server (even though I consider myself an enterprise developer). If I would build one I would simply demand full control of the application server and that it is only used by our application. This means that security can be switched off, all beans can do anything.
Yeah, and the IT department at your customer company, which just invested $X millions in a state of the art WebSphere cluster with HA can just go screw themselfes? Because you will not sell your software unless you get your own private instance? =)
Actually, security managers can be a great way to enforce standards, such as that EJB´s cant access a local file system. If you really, really, want to, and you know what youre doing, you can disable the restriction, but its there to stop those who doesnt know, or even understand, about it from messing up.
|
|
|
Message #216582
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
security manager
Which servers have you deployed to that enable the security manager? What issues did you find through this, if any, and how did you work around them? Do you think simple removal of the security manager is an acceptable workaround?
I used SUN Java Aplication Server and it has security manager enabled by default. I had some issues with Hibernate but its not so hard to tweak security policy file. I don't think that removal of security manager is an acceptable option.
|
|
|
Message #216583
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Security Managers: do you use them? For what?
Yeah, and the IT department at your customer company, which just invested $X millions in a state of the art WebSphere cluster with HA can just go screw themselfes? The clients we have all do not use an application server. They just want a website, that the website is mission critital they do not really see themselfs; since we as IT specialists do see that we build in enterprise features to provide stability, scalability, transactions, logging, etc.
Because you will not sell your software unless you get your own private instance? =) I only do that to enforce security the client himself does not think about, he probably does not even want to think about it.Actually, security managers can be a great way to enforce standards, such as that EJB´s cant access a local file system. If you really, really, want to, and you know what youre doing, you can disable the restriction, but its there to stop those who doesnt know, or even understand, about it from messing up. I agree: I love standards and I love to use them, but please tell that to my client that does not want to pay for using those standards and who really doesn't care about them as long as the product works correctly as he specified. I can give my client two options: either buy yourself a new server dedicated for my stand alone application (approx. 5000 EUR) for more security or let a few developers make sure that the stand alone application is secure (approx. 10000 EUR). Or even better: build the application from day one completely in EJB for running in an application server that would double the entire price from day one. What do you think he will choose?
|
|
|
Message #216620
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Security Manager : A Bane
While developing a tapestry based application on Sun Platform( We used SUN JES Application server) we had to tweak a lot of code to get around the java security model. Tapestry uses class enhancements a lot and there is no way one can give permissions to a enhanced class. To be very frank java security hampers application development as opposed to tighten application security. One can always provide specific code base specific security permissions to get around it. So whats the use?
|
|
|
Message #216635
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SecurityManager can be useful; most app servers don't enable it
Everyone here should know of the long-standing EJB spec restrictions on actions such as writing to the file system or starting a Thread in an EJB. But also know that most app servers never enforced these limitations. I do remember working with ISP hosting companies back when I worked on JRun, before its J2EE server days, and they were wondering how to safely isolate customer apps within the same JVM instance, which wasn't really do-able at the time and still isn't (except maybe the Java Isolates API (http://jcp.org/en/jsr/detail?id=121), which only has an RI for Solaris, AFAIK). And explaining a Java HOW-TO for security policies and such to ASP or PHP hosts at the time was a real challenge.
Enabling the Java SecurityManager and enforcing any kind of security policy can incur serious performance overhead as the JVM suddenly has to check all method invocations for permissions.
However, enabling the SecurityManager and writing up a security policy is sometimes a good measure to ensure that logically private APIs cannot not used. Other measures along those lines are obfuscating your byte code and removing the debug information from class files. But these measures make your code much more difficult to debug in the field.
|
|
|
Message #216713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SecurityManager can be useful; most app servers don't enable it
Enabling the Java SecurityManager and enforcing any kind of security policy can incur serious performance overhead as the JVM suddenly has to check all method invocations for permissions.
However, enabling the SecurityManager and writing up a security policy is sometimes a good measure to ensure that logically private APIs cannot not used.
Well, I believe that WebSphere, for instance, uses this measure by default for a secured server, and it doesnt seem to hurt performance for a *real* system much.
On the other hand, asking a customer to disable this, just because your code cant live with it, will damage something - your credibility.
|
|
|
Message #216862
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Customers know about SecurityManager? I doubt it
Come on. Besides, even if this is true (prove it), what does enabling the SecurityManager do for you if you don't have any policy defined? It's useless.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
