Reference architecture of secure webSpoon

HTTPS can be configured in Tomcat/Jetty. If webSpoon is deployed to Tomcat, please refer to here.

Edit WEB-INF/web.xml to uncomment/enable user authentication.

  <!-- Uncomment the followings to enable login page for webSpoon
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      /WEB-INF/spring/*.xml
    </param-value>
  </context-param>

  <filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  -->

Edit WEB-INF/spring/security.xml to configure authentication providers. The examle below uses two auth providers: ldap-authentication-provider and authentication-provider, where the LDAP authentication is provided by the Spring Security's embedded LDAP server with a configuration of WEB-INF/classes/example.ldif. See here for Spring Security in general and here for LDAP.

  <!--<ldap-server url="ldap://localhost:389/dc=example,dc=org"/>-->
  <ldap-server ldif="classpath:example.ldif" root="dc=example,dc=org"/>

  <authentication-manager>
    <ldap-authentication-provider user-dn-pattern="uid={0},ou=people"
      group-search-base="ou=groups" />
    <authentication-provider>
      <user-service>
        <user name="user" password="password" authorities="ROLE_USER" />
      </user-service>
    </authentication-provider>
  </authentication-manager>

As some users have already noticed, webSpoon users can browse the file system of the server and can access files/directories that are accessible by the user who runs webSpoon. For example, if the root user runs webSpoon, webSpoon users can read/write all files of the server. This also means that all webSpoon users gain the same access privileges.

An immediate solution for this issue is to restrict access to the local files by

• Containerize webSpoon (e.g., Docker) and isolate from the outside
• Run webSpoon in a chrooted Tomcat

In addition, it is recommended to use files in a file server such as SFTP for data inputs/outputs. You can use VFS to access those files. There are many supported file systems: SFTP, HTTPS, WebDAV; and some of them have a user authentication mechanism.

Pentaho Enterprise Repository offer a user authentication and a fine-grained access control to Kettle files. For this reason, the author (@HiromuHota) recommends using Pentaho Enterprise Repository in webSpoon.

End-users can be restricted from accessing to the local file system by enabling a (custom) security manager as follows.

1. Enable user authentication
2. Copy webspoon-security-8.2.0.0-342-XX.jar to "$CATALINA_HOME"/lib
3. Edit bin/setenv.sh as CLASSPATH="$CATALINA_HOME"/lib/webspoon-security-8.2.0.0-342-XX.jar
4. Create $HOME/.kettle/users and $HOME/.pentaho/users if not exist
5. Define environment variables and restart Tomcat

$ export CATALINA_OPTS="-Djava.security.manager=org.pentaho.di.security.WebSpoonSecurityManager -Djava.security.policy="$CATALINA_HOME"/conf/catalina.policy"
$ ./bin/startup.sh

Your policy file "$CATALINA_HOME"/conf/catalina.policy should include the following permissions.

grant
{
  permission java.io.FilePermission "${java.io.tmpdir}", "read";
  permission java.io.FilePermission "${java.io.tmpdir}/-", "read,write,delete";
  permission java.io.FilePermission "${catalina.home}/webapps/spoon/rwt-resources", "write,delete";
  permission java.io.FilePermission "${catalina.home}/webapps/spoon/rwt-resources/-", "read,write,delete";

  permission java.io.FilePermission "${java.home}/lib/-", "read";
  permission java.io.FilePermission "${catalina.home}/webapps/spoon/-", "read";
  permission java.io.FilePermission "${user.home}/.pentaho", "read";
  permission java.io.FilePermission "${user.home}/.pentaho/metastore", "read";
  permission java.io.FilePermission "${catalina.home}/lib/-", "read";
  permission java.io.FilePermission "${catalina.home}/plugins/-", "read";
  permission java.io.FilePermission "${catalina.home}/ui/-", "read";
  permission java.io.FilePermission "${catalina.home}/-", "read";
  permission java.io.FilePermission "${catalina.home}/.", "read";
  permission java.io.FilePermission "repositories.xml", "read";
};

org.pentaho.di.security.WebSpoonSecurityManager is a security manager, tailor-made for webSpoon. It was designed so that only local file access triggered by end-users (more precisely UIThread and its child threads) is controlled. If it is enabled, end-users can only access $HOME/.kettle/users/$username and $HOME/.pentaho/users/$username except for those listed in the policy file.

This effectively restricts steps and job entries such as "Shell" from running because spawning another process requires access to <<ALL FILES>> (meaning anywhere in the local file system). However, this does not apply to "User Defined Java Class" and "Modified Java Script Value" because they are executed within JVM. They are restricted only from accessing outside of permitted directories and not from running.

The custom security manager and SpoonGit can be used simultaneously with a few restrictions, but requires following configurations.

1. Define an environment variable export GIT_CONFIG_NOSYSTEM=True
2. Add the following permissions to your policy file:

grant {
  permission java.io.FilePermission "${user.home}/.gitconfig", "read";
  permission java.io.FilePermission "${user.home}/.gitignore_global", "read";
}

Restriction 1: Hooks do not work. If hooks are present in .git/hooks and are executable, an error access denied ("java.io.FilePermission" "<<ALL FILES>>" "execute") will occur. Please remove those hooks or do not enable the custom security manager.

Restriction 2: Use HTTP(S) instead of SSH. Technically, SSH can be used with the following permissions, but no one wants to do this because every end-user will be using the same (git) user and will have access to the private keys.

grant {
  permission java.io.FilePermission "${user.home}/.ssh", "read";
  permission java.io.FilePermission "${user.home}/.ssh/-", "read";
}

Let me assure you that username and password used for the HTTP(S) authentication are cached for your convenience during the session, but not shared with other end-users.

You might want end-users to be restricted from using some step or job entry. To do so, take the following steps:

1. Download kettle-steps.xml and kettle-job-entries.xml to under $CATALINA_HOME
2. [IMPORTANT] Rename these XML files (to kettle-steps-alternative.xml and kettle-job-entries-alternative.xml for example)
3. Edit the XML files so that only steps/job entries that are allowed to use are listed
4. Restart Tomcat with the following environment variable

export JAVA_OPTS="-DKETTLE_CORE_STEPS_FILE=kettle-steps-alternative.xml -DKETTLE_CORE_JOBENTRIES_FILE=kettle-job-entries-alternative.xml"

Note that these XML files can only list internal steps and job entries. If you want to restrict plugins, simply remove them from ./plugins.