Information

  • PLANTA secure provides a higher standard of security using the two-factor authentication (2FA) which is recommended by the German Federal Office for Information Security.
  • For more information, please contact your PLANTA consultant.

PLANTA secure components

Installation Instructions

Information

  • The server adapter must be configured as described in the corresponding section below and must be made available in a server container. A direct TCP connection to a preexisting PLANTA Server and authentication for single sign-on via proxy are required.
  • Once you have set the application configuration as outlined in the corresponding specific section below, the Client Adapter can be used as-is. An existing PLANTA Client must be available.
  • Common authentication methods of the company, like smart cards, can be addressed via respective plug-ins. For more information, please contact your PLANTA consultant.

PLANTA Server

Information

  • The configuration of the PLANTA Server can remain unchanged, unless single sign-on via proxy authentication is desired.
  • In the config/globals.conf configuration file, the 'proxy' extension must be added to the authentication method command in order to permit proxy pre-authentication. This will make sure that the incoming connections are trusted and that the specified user ID is logged on without any further checks.
    • The risk is thus the same as in OS user-login, except that here the server adapter is the party which is trusted blindly instead of the client. Hence, the connection to the Server Adapter needs to be encrypted and authenticated for this scenario to be secure!
  • In the ppms.proxy_auth Python module, there is a predefined proxy_auth_resolve_username(proxy_user) method which called by the Server. It is supposed to return the PLANTA user ID to log on to the system. The default implementation will pass on the proxy user ID.

Details

  • The server adapter is now integrated in the server and runs as a servlet in an integrated application server.
  • This feature must be activated via the license file.
  • The configuration is adjusted in the following files: config/globals.conf, config/secure.conf and config/ldap.conf
  • The server adapter has been extended by authentication via LDAP. This also requires a current ClientAdapter.

Information

  • The configuration of the PLANTA Server can remain unchanged, unless single sign-on via proxy authentication is desired.
  • In the config/globals.conf configuration file, the 'proxy' extension must be added to the authentication method command in order to permit proxy pre-authentication. This will make sure that the incoming connections are trusted and that the specified user ID is logged on without any further checks.
    • The risk is thus the same as in OS user-login, except that here the server adapter is the party which is trusted blindly instead of the client. Hence, the connection to the Server Adapter needs to be encrypted and authenticated for this scenario to be secure!
  • In the ppms.proxy_auth Python module, there is a predefined proxy_auth_resolve_username(proxy_user) method which is called by the Server. It is supposed to return the PLANTA user ID to log on to the system. The default implementation will pass on the proxy user ID.


Server Adapter

Information

  • The server adapter comes as a Java Servlet that can be configured
    • Backend: is automatically copied from globals.conf.
    • Other settings are to be adjusted in config/secure.conf.
    • The LDAP interface settings are summarized in config/ldap.conf.
    • Logging: has been integrated in the config/logback.xml of the server.

Details

  • In order to satisfy security requirements, this application server instance must be configured in a way that only trusted requests from the reverse proxy are allowed, i.e. HTTPS with mutual authentication.
  • The TCP connection between server adapter and PLANTA Server is not encrypted by default. SSL can be activated by carrying out the following steps:
    • replacement of keystore.jks and truststore.jks in the config directory
    • execution of planta_ssl as a back-end protocol and
    • configuration of the respective password in config/secure.conf

Information

  • The server adapter comes as a Java Servlet that can be configured
    • in terms of deployment: via the standard WEB-INF/web.xml,
    • in terms of the backend: via the self-documenting WEB-INF/classes/config.properties and
    • in terms of logging: via WEB-INF/classes/logback.xml.

Details

  • The existence of an application server in which the servlet can be made available is a prerequisite for a secure setup. The environment must support the JAVA servlet API version which corresponds to the status of your secure components. For further information, please see the Release Notes for the version employed by you. In order to satisfy security requirements, this application server instance must be configured to allow only trusted requests from the reverse proxy, i.e. HTTPS with mutual authentication. Here it is exemplified how Let's Encrypt certificates are stored in the tomcat server.
  • The TCP connection between server adapter and PLANTA Server is not encrypted by default. SSL can be activated by carrying out the following steps:
    • replacement of keystore.jks and truststore.jks in the web archive
    • execution of planta_ssl as a back-end protocol and
    • configuration of the respective password in config.properties


Reverse Proxy

Information

  • The BOSH protocol, which is used by PLANTA to establish a connection, does not work with HTTP pipelining and is disabled in the client adapter. Hence the reverse proxy must not employ HTTP pipelining when forwarding requests to the Server Adapter.
  • Persistent connections as of HTTP 1.1 / keepalive should be enabled for improved latency and throughput, esp. when using SSL-encrypted connections.

Details

  • The value specified for bosh.session.max_wait in the servlet's config.properties is the lower bound for the reverse proxy's read timeout; otherwise polling requests may be aborted with a 504 gateway timeout error.
    • This can just as well be taken care of the other way around - if a lower maximum request timeout is desired, max_wait should be slightly below that value in order for polling requests not to run into trouble.
  • If proxy authentication is enabled in the Server Adapter, the name of a HTTP header containing the user ID can be configured. The value of this field is passed on to the PLANTA Server as-is. Further processing is subject to customizing. See the "PLANTA Server" section for further information.

Here is a sample nginx configuration excerpt for a working reverse proxy setup

http {
    server {
        location /planta {
            # servlet location as defined during deployment
            proxy_pass http://servletcontainer.example.com:8080/PLANTAServerAdapter/;

            # read timeout needs to be be set >= the value of
            # bosh.session.max_wait in the servlet's config.properties, which
            # defaults to 900
            proxy_read_timeout  900s;

            # persistent connections as per http keepalive improve both latency
            # and throughput, esp. with SSL connections
            proxy_http_version  1.1;
            proxy_set_header Connection  "";

            # just push some dummy value as proxy-authenticated user
            proxy_set_header iv-user nobody;
        }
    }
}
PY

Client Adapter

Information

  • The Client adapter is integrated in the PLANTA Client and can be configured in the planta.ini.
  • The Client Adapter will pass on all command line arguments to the client. A potential server= parameter will be removed since the Client Adapter provides its own host and port, effectively rerouting the client connection to itself.

Information

  • The client adapter comes as a .NET client application which can be configured via self-documenting application configuration, PlantaClientAdapter.exe.config.
  • The Client Adapter will pass on all command line arguments to the client. A potential server= parameter will be removed since the Client Adapter provides its own host and port, effectively rerouting the client connection to itself.