Apply Java Permissions to Domino Agents at runtime - again ;-)

This post is supposed to be read by developers only. Admins, please move on ;-)

I have an agent which is used to make SFTP file transfers from Domino to our corporate SAP system. It's an interesting project and I am exploring new stuff on a daily basis :-)

One technical issue I had to solve was this:
The agent opens an SFTP session on a remote host. Unfortunately this is forbidden by Java Policies specified in the java.policy file of the JVM of the Domino server.
The error is
java.lang.SecurityException: not allowed to make a socket connection to MYHOST.MYDOMAIN.COM,-1

So I started to dig into java.policy and java.pol files. And to be honest I was not that much pleased about the whole thing. At first I started to grant ANY permissions in the global section of my policy file:

 grant {   
  ...  
  permission java.security.AllPermission;  
  ...  
 };   

This works but it goes a bit over the top for a productive environment... Therefore I started to tweak the policies to only allow one specific application the network operations required to do the job. Honestly, it's been painful... I think I got it more or less configured properly. But given the fact that we run the application in three different environments (DEV/TEST/PROD) on multiple servers I hardly could imagine a proper rollout scenario. I always thought one of the major strengths of domino and NSF was that usually the design and resides in a single database - and the configuration usually resides in the application, a few system databases (+ notes.ini).

There must be an easier way to grant my code the execution rights it needs.
I finally found a solution to grant my code the needed execution rights at runtime of the agent. There is a whole Java package for handling the permissions - and in my particular case I was looking for SocketPermissions. The code to grant a socket permission is pretty straight forward:

 String hostAndPort = "myhost.mydomain.com:22";   
 SocketPermission p = new SocketPermission(hostAndPort,  
       "accept,connect,resolve");  

This will allow my code to make a network connection to the specified host on the specified port. There might be neater solutions to that problem and not every admin would be happy about that. In my opinion it is not very consistent for what you need to grant permissions in policy files (like network connects) but on the other hand file handling can be allowed on the agent security (Allow restricted operations).

Today I learned how to override session authentication using a web site rule

Did you know that you can override session based authentication based on URL patterns?‎ Yes? Lucky you, I didn`t. I honestly admit it: I am more a developer than an admin ;-). The feature dates back to R7.0.2 so I must have been missed something at that time...

In one of my projects domino provides a web service which can be consumed by a 3rd-party-system. All sites on that server (R8.5) are configured to use  session-based authentication. Since web services cannot authenticate via basic authentication (at least I did not get it working) I  was looking for a way to work around session based authentication. An additional web site involves a lot of effort and patience in this environment as there are quite a few people involved. 

Finally I got the right hint from the developer who consumes the web service. There is a web site rule for that! And I just did not know about it:-o

The setup is quite straight forward. Open an Internet Site document and click on Web Site - Create Rule and select "Override Session Authentication" as type of rule.

You can specify a URL pattern for which domino overrides session based authentication. On the one hand this provides a lot of flexibility‎. On the other hand, the pattern should be chosen with care. Wildcards (*) can be applied too.

So, this is it, my lesson learned today.