How API proxy can access file from file system

Not applicable

Business requirement is to retrieve customer's phone bill on demand as requested by mobile subscriber from Mobile App. These bills (pdf files) are available as part of the SAN storage that can be mounted on Edge (MessageProcessors) servers.

I understand, due to security requirements, Edge apply sandbox approach and doesn't allow proxy (including Node.js, Java callout, etc.) to access file system. Also, ftp endpoint is not supported. Is my understanding correct?

This installation is a Private cloud installation and as I understand, private cloud installation allows to enable additional configuration like large response payload, etc. Is their any specific configuration that can allow to read file?

In the absense of above configuration; custom solution like implementing http interface as Southbound of Edge. This will include additional effort like implementing http interface and including QoS requirements like HA, Scalability, etc. Is their any other solution available?

Number of requests in in the range of 2 tps.

Solved Solved
1 6 747
1 ACCEPTED SOLUTION

When deploying Edge on a private cloud, the administrators have access to the java security policy files that govern the things a Java callout can and cannot do when run within a Message Processor. The MP is just a Java app, and the security restrictions that apply to the Java callouts are governed in the standard Java way, via the security policy file. This is described in the Java documentation, here.

For Edge 16.01 and beyond, you can find the security policy for the Message Processor here:

/opt/apigee/edge-message-processor/conf/security.policy

In that file, you will find some existing grants, as well as guidance on how to relax permissions. For example, here's the restriction on java callouts:

// javacallout code has just read permission in the installed dir and everything below it
grant codeBase "file:${javacallout.dir}/-"  {
    permission com.apigee.securitypolicy.AllExcept "50";
    permission java.io.FilePermission "${javacallout.dir}/-" , "read";
}

So it is not quite right that the Java callout cannot access the filesystem at all. It can access its own installation dir and everything below it. But it IS true that the callout cannot access anything outside that directory.

If you would like to grant broader permissions to all Java callouts, or even to specific Java callouts, you can do so by modifying this file. For example, this will grant read permission on a specific directory to a specific Java callout:

grant codeBase "file:${javacallout.dir}/my-Specific-Callout-1.0.0.jar" {
  permission java.io.FilePermission "/opt/san-mount-dir/-" , "read";
}

You could also grant such broader read permissions to all Java callouts, by eliminating the specific jar name in the above and replacing it with a dash.

If you decide to change the security policy file, you will want to use the token-based configuration for OPDK, as described here. The relevant file for the Java security.policy is /opt/apigee/edge-message-processor/source/conf/security-policy.properties .

Specify a new policy file there, and insert the right grants for the javacallout.dir. This makes it possible to preserve your changes, even across upgrades to Apigee Edge.

Be sure to:

  • ensure your changes are applied uniformly across all message processors in the cluster
  • Restart each MP in your cluster after making modifications

View solution in original post

6 REPLIES 6

When deploying Edge on a private cloud, the administrators have access to the java security policy files that govern the things a Java callout can and cannot do when run within a Message Processor. The MP is just a Java app, and the security restrictions that apply to the Java callouts are governed in the standard Java way, via the security policy file. This is described in the Java documentation, here.

For Edge 16.01 and beyond, you can find the security policy for the Message Processor here:

/opt/apigee/edge-message-processor/conf/security.policy

In that file, you will find some existing grants, as well as guidance on how to relax permissions. For example, here's the restriction on java callouts:

// javacallout code has just read permission in the installed dir and everything below it
grant codeBase "file:${javacallout.dir}/-"  {
    permission com.apigee.securitypolicy.AllExcept "50";
    permission java.io.FilePermission "${javacallout.dir}/-" , "read";
}

So it is not quite right that the Java callout cannot access the filesystem at all. It can access its own installation dir and everything below it. But it IS true that the callout cannot access anything outside that directory.

If you would like to grant broader permissions to all Java callouts, or even to specific Java callouts, you can do so by modifying this file. For example, this will grant read permission on a specific directory to a specific Java callout:

grant codeBase "file:${javacallout.dir}/my-Specific-Callout-1.0.0.jar" {
  permission java.io.FilePermission "/opt/san-mount-dir/-" , "read";
}

You could also grant such broader read permissions to all Java callouts, by eliminating the specific jar name in the above and replacing it with a dash.

If you decide to change the security policy file, you will want to use the token-based configuration for OPDK, as described here. The relevant file for the Java security.policy is /opt/apigee/edge-message-processor/source/conf/security-policy.properties .

Specify a new policy file there, and insert the right grants for the javacallout.dir. This makes it possible to preserve your changes, even across upgrades to Apigee Edge.

Be sure to:

  • ensure your changes are applied uniformly across all message processors in the cluster
  • Restart each MP in your cluster after making modifications

@Dino Many thanks for detailed answer. We will try it out and update at this post.

Thanks @Dino,

You are a saviour man.

I had tried using Node and symlinks, but symlinks did not work.

This worked perfectly.

Glad to help!

I'm updating

/opt/apigee/edge-message-processor/conf/security.policy as per above but when I restart MP, it overwrites my changes.

Ryan, yes, that's expected.

It's a little indirect. Rather than changing the security.policy file directly, you need to make the changes in the message-processor.properties file.

To query the existing security.policy file:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor configure -search conf_security-policy_policy.file

You should see something like:

Found key conf_security-policy_policy.file, with value, conf/security.policy, in /opt/apigee/edge-message-processor/token/default.properties

To make the change, you need to edit the file /opt/apigee/customer/application/message-processor.properties . Ensure it has a line like this:

conf_security-policy_policy.file=customer/conf/my.security.policy

And then place into the file /opt/apigee/customer/conf/my.security.policy , the appropriate grants and permissions. You can name the file anything you like. The path is relative to /opt/apigee . Ensure the file is readable by the apigee user.

After that, restart the MP:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Then, query the security.policy file again, as above. You should see the new security policy file in effect.

For reference information on this approach, see: https://docs.apigee.com/private-cloud/latest/how-configure-edge