Upgrade from 1.9 to 2.0

As usual, if you use more than 1 server and don't want to stop the SSO service AND IF YOU HAVE NO INCOMPATIBILITY MENTIONED IN THIS DOCUMENT, upgrade must be done in the following order:

1. servers that have only handlers;
2. portal servers (all together if your load balancer doesn't keep state by user or client IP and if users use the menu);
3. manager server

This release of LL::NG requires these minimal versions of GNU/Linux distributions:

• Debian 9 (stretch)
• Ubuntu 16.04 LTS
• CentOS 7
• RHEL 7

For SAML features, we require Lasso 2.5.

• User module in authentication parameters now provides a “Same as authentication” value. You must revalidate it in the manager since all special values must be replaced by this (Multi, Choice, Proxy, Slave, SAML, OpenID*,…)
• “Multi” doesn't exist anymore: it is replaced by the more powerful Combination
• Apache and Nginx configurations must updated to use the FastCGI portal
• URLs for mail reset and register pages have changed, you must update configuration parameters. For example:

  mailUrl => 'http://auth.example.com/resetpwd',
  registerUrl => 'http://auth.example.com/register',

• A new Kerberos authentication backend has been added since 2.0. This module solves many Kerberos integration problems (usage in conjunction with other backends, better error display,…). However, you can retain the old integration manner (using Apache authentication module).
• For SSL, a new Ajax option can be used in the same idea: so SSL can be used in conjunction with other backends.

• Syslog: logs are now configured only in lemonldap-ng.ini file. If you use Syslog, you must reconfigure it. See logs for more.
• Apache2: Portal doesn't use anymore Apache2 logger. Logs continue to be written to Apache error.log but Apache “LogLevel” parameter has no effet on it: portal is now a FastCGI application and doesn't use anymore ModPerl. See logs for more.

LLNG portal now embeds the following features:

• CSRF protection (Cross-Site Request Forgery): a token is build for each form. To disable it, set requireToken to 0 (portal security parameters in the manager)
• Content-Security-Policy header: portal build dynamically this header. You can modify default values in the manager (Général parameters » Advanced parameters » Security » Content-Security-Policy)

• CDA, ZimbraPreAuth, SecureToken and AuthBasic are now Handler Types. So there is no more special file to load: you just have to choose “VirtualHost type” in the manager/VirtualHosts.
• Apache only: because of an Apache behaviour change, PerlHeaderParserHandler must no more be used with “reload” URLs (replaced by PerlResponseHandler). Any “reload url” that are inside a protected vhost must be unprotected in vhost rules (protection has to be done by web server configuration).

• hostname() and remote_ip() are no more provided to avoid some name conflicts (replaced by $ENV{})
• $ENV{<cgi_variable>} is now available everywhere: see Writing rules and headers
• some variable names have changed. See variables document

• Apache-1.3 files are not provided now. You can build them yourself by looking at Apache-2 configuration files

Before 2.0, an Ajax query that was launched after session timeout received a 302 code. Now a 401 HTTP code is given in response. The WWW-Authenticate header contains: SSO <portal-URL>

• SOAP server activation is now split in 2 parameters (configuration/sessions). You must set them else SOAP service will be disabled
• Notifications are now REST/JSON by default. You can force old format in the manager. Note that SOAP proxy has changed: http://portal/notifications now.
• If you use “adminSessions” endpoint with “singleSession*” features, you must upgrade all portals in the same time
• SOAP services can be replaced by new REST services

Portal has now many REST features and includes a plugin API. See Portal manpages to see how to write auth modules, issuers or other feature.

Portal is no more a big CGI object. it is written for Plack/PSGI. Little resume

Portal object
  |
  +-> auth module
  |
  +-> userDB module
  |
  +-> issuer modules
  |
  +-> other plugins (notification,...)

The request is a separated object based on Lemonldap::NG::Portal::Main::Request which inherits from Lemonldap::NG::Common::PSGI::Request which inherits from Plack::Request. See manpages for more.

Handler libraries have been totally rewritten. If you've made custom handlers, they must be rewritten, see customhandlers.

If you had auto protected CGI, you also need to rewrite them, see documentation.