Usability - Productivity - Business - The web - Singapore & Twins

Java security in XPages

Once you push the boundaries of XPages (which are very elastic) you sooner or later will run into Java security. The Java security settings live in the file
[notes program]/jvm/lib/security/java.policy. The text file (don't edit it in Symphony, use gEdit or Notepad) defines a series of grant codebase "somelocation" { Java Permission } entries that govern what code located at a specific location is allowed to do and what not. The general rule: it must be allowed, otherwise it is forbidden. The basis entry grant { ... } defines what all Java classes can do. You definitely want to be very stingy here. Lazy developers (like me) add to this file:
grant { permission java.security.AllPermission; };
... which is of course a big No No for a production environment (but a big Yes Yes for a productive dev environment - waiting for the howls). When you are ready to deploy your Java infested enhanced nsf, you need to update the java.policy file on your target machine (waiting for another howl) - unless you were smart and packaged your Java into an extension library which has the right level of security and is easy to deploy). The syntax is easy (but not necessarily logical for us mere mortals):
grant codeBase "xspnsf://server:0/yourdatabase.nsf/-" {
permission java.security.AllPermission;

Jim clarifies: you only need to change yourdatabase.nsf, the other parts are static, directory separators are / regardless of platform, the location is relative to the data directory and the whole codeBase value must be lower case (regardless of your file names). Of course you can limit the permission to what you actually need. Finding out what that is when you use ready baked libraries can be a little tedious and warrants its own future post.

Posted by on 21 July 2011 | Comments (e) | categories: XPages


  1. posted by Nathan T. Freeman on Thursday 21 July 2011 AD:
    java.policy-based security management...


    "...which is of course a big No No for a production environment..."

    Why? Because then the server might be a capable application platform or something?

    I really wish people would stop selling this line that opening up the language capabilities is a bad thing in a production environment. It's not. It's a good thing. Java security management shouldn't be used to prevent whatever it is that's being prevented. Notes PKI signatures and server security settings are the well-established and understood mechanisms to control the behavior of Domino applications.

    The inclusion of java.policy and it's default settings has created a perception among Domino administrators that enabling the platform is "dangerous." Because, y'know, letting Java programs write files to the drive or access network sockets is risky, but letting Lotusscript programs do it is JUST FINE.

    Some days I'm tempted to create a scheduled agent to put the grant {AllPermissions} into the java.policy using Lotusscript, and then just start smuggling it into people's directory templates or something. :-/

    Here's a hint for those that are confused: if I have Java code running on your Domino server and I want to do something malicious, the java.policy terms are the least of your problems. I'll do interesting things like email the server id file to myself, or randomly re-write data in fields in your NSFs, or inflate some local files until your server runs out of disk space, or alter the design of the ($ServerAccess) view so that my name is hardcoded into every non-DenyAccess group in your entire directory.

    And instead Domino product management wants to put this fig-leaf protection to keep XPages applications from doing HTTP GET requests on a server!??!?!

    It's just stupid.
  2. posted by Erik Brooks on Thursday 21 July 2011 AD:
    @1 - Agreed. All this does is scare new-to-Java Notes/Domino devs.

    "IBM gave me a toggle in the IDE to let my agent work with system files, etc.... but for Java I have to edit a text file? Wow, that must be REALLY dangerous. And unsupported, I'm sure."

    The fact that the Java security settings are blown away when you upgrade server versions or install a FP is also a total PITA.
  3. posted by Simon O'Doherty on Thursday 21 July 2011 AD:
    The Java code execution is normally controlled by the ACL and execution rights/server document.

    Some stuff needs to go back to java.policy but not everything (I think taking screen shots of the servers desktop would be one as an example).

    Agree with Nathen though. I am of the belief that you should never allow any developer the ability to write code directly to your production server. Admin should always hold those keys.
  4. posted by Stephan H. Wissel on Friday 22 July 2011 AD:
    Ah... Nathan, you took the No-No bait Emoticon smile.gif The general idea would be that NSF based Java code can't do network things that your average browser JS can do since it comes from the server (whatever impact that has in a security architecture). Once you deploy your application that needs to do more you sit down with your Notes Admin, walk through what the code is doing and faithfully the Notes Admin edits the java.policies file on the server. Just when he was about to hit save....
    your alarm clock rang and you wake up.

    Yes - bad idea. Why do you think I wrote the Plug-in deployer that doesn't need an admin edit any file. Sidesteps the issue. But with a few lines there we could solve the policy settings too Emoticon biggrin.gif
  5. posted by Nathan T. Freeman on Friday 22 July 2011 AD:
    @Simon, LOTS of stuff goes back to the java.policy. All network socket access, for example. Or access to the Java Loggers. Or anything involving Class Loaders.

    @Stephan, I might be interested in discussing the issue with a NotesAdmin, if any of them besides Andrew Pollack actually knew what the java.policies represent. 99.99% of Domino administrators are MESSAGING administrators that have no idea what an application server is supposed to do. (Hence the reason they think it's risky to deploy the OpenNTF Extension Library, for example.)
  6. posted by Karsten Lehmann on Friday 22 July 2011 AD:
    Because of the Java security restriction (and of course software architecture reasons), we are not putting much code in NSF databases, but develop Eclipse plugins instead. There we can use AccessController.doPrivileged() calls to execute code with full rights and don't need to mess around with the java.policy file that btw is stored in the program directory of Notes/Domino, so I guess it would not be that easy to modify the file on a server from LotusScript because of file system access restrictions (applications should not be able to modify the content of program/system folders).

    In one of our customer projects, we don't have ANY design element besides a single forwarding XPage and Notes views in the database, because the complete UI and application logic is coming from plugins (the UI is Ext.js based anyway and uses REST services to load/store data, so all the JSF stuff from XPages would produce more problems than it solves).
    I like that approach a lot. We can control the whole data/ui lifecycle in our own code. If any error occurs, we can fix it and don't have to wait for IBM/the next release or find a workaround.
    The OSGi support of XPages in 8.5.2 makes it possible.

    But of course I understand that most of the developers prefer rapid application instead and don't want to become Eclipse experts.

    For 8.5.3, deploying plugins on a Domino server should be a matter of a putting the NSF update site on the server and setting the right Notes.ini variable. Then the HTTP task's OSGi loads the plugins from the update site automatically.
    As Stephan mentioned, for 8.5.2 there is the plugins deployment tool project from OpenNTF.

    What's missing is an NSF based deployment method to bring plugins to the local Notes Client. You can do this via policies, but that involves talking to the admin for each update and is not dynamic enough for quick plugin changes that a developer makes and wants to send it to a test person.

    We are working on such a solution, but need to clarify with IBM's Expeditor development, if our code would work in all cases.
  7. posted by Chris Hudson on Friday 22 July 2011 AD:
    I resent the implication that 99.99% of administrators have no clue about what an application server is.

    I could be just as inflammatory by stating that 99.99% of application developers have no clue about security and are all cowboys. But I know that's not true.

    So long as an application developer can show me that he/she has thought about the security implications of their application and have documented the access requirements of their code I am quite happy to give them the access they need. If they just ask for carte blanche access because 'you know, my code might need it and I had that access on my local PC, so I know it works, then they are going to get a no from me because they have not gone to any effort to even think about security.
  8. posted by Nabor on Tuesday 02 April 2013 AD:
    I tried the above grant on our Domino 9 Server but it seems not to work.
    My Java Class in the Domino Database only works if I grant AllPermissions on the global grant block.
    Any Ideas?
  9. posted by Stephan H. Wissel on Tuesday 02 April 2013 AD:
    @Nabor: one million reasons... Is your nsf name lowercase? Is the path correct? No .dir file involved? Database signed properly? If in doubt: Open a PMR!

    @Chris: the cowboy remark works as a compliment

    Emoticon biggrin.gif stw
  10. posted by Fred on Wednesday 22 May 2013 AD:
    Same for me.. it works on the global grant block, but as soon as i want to narrow it down to a DB, it doesn't..

    no .dir file involved
    all signed with server id
    database spelled correctly (all lower)
  11. posted by Franz on Tuesday 11 June 2013 AD:
    Does anyone know about a notation that will allow a Java agent to run? The above only seems to work for XPages.
  12. posted by Fanz on Tuesday 11 June 2013 AD:
    Stephan, thanks a bunch for the quick response. I feared as much, but I guess it never hurts to ask.
  13. posted by Stephan H Wissel on Tuesday 11 June 2013 AD:
    @Franz: Java agent security is governed by 2 elements: your (server or client) ECL and the Java policies (found in java.policies and java.pol. For a Java agent, if adjusting the ECL isn't sufficient, you have to deploy the code as JAR into jvm/lib/ext. You can use a LotusScript agent for that. The agents are not database aware on a JVM level, so your policy edits need to be class based, not location based.

    In short: No
  14. posted by Dexter Madronio on Thursday 15 May 2014 AD:
    @Stephan, I was having a look at your Plugin Deployer and I just wanted to validate with you that it doesn't have the capability to make changes to the trusted java folder (jvm/lib/security), right? Is that something you might be adding later on? Thanks for helping us non Java devs Emoticon smile.gif .