According to saml2int 0.2, the assertion element must be directly signed, which we do. This suffices for most SP's. However, some SP's require the outer Response element to be signed directly. If configured to do so for that SP, Engineblock will sign the outer response element in addition to the signed Assertion element.
Therefore if the option metadata:coin:sign_response
on the SP is set the response will be signed. Also a migration Version20190425205743
is added to add the required column.
To support rolling-updates this migration needs to be executed before updating the code and before the rolling update column cleanup migrations as described below.
The memory used in php for the metadata push is now configurable with the engineblock.metadata_push_memory_limit
configuration option.
The features from 5.8.3 to support rolling updates have been dropped as they are no longer used.
Running the migrations Version20180910134145
and Version20180910175453
will take care of this.
Be aware that the logic used to update the columns are also dropped in this release. So you first have to update the
code and after that you should run the migrations to drop the columns.
The features were introduced in 5.8 but were partially reverted to support rolling updates in 5.8.3 because in these features table columns were dropped. To be able to role back to a version before 5.8.3 while maintaining database integrity both version were kept. Currently the columns aren't used anymore so therefore the old implementations could be dropped completely.
Metadata pushed to EngineBlock in earlier versions (EB<5.8) is not compatible with this version. A metadata push is required after upgrading to EB 5.8. In order to upgrade from 5.7 to 5.8 you need to go to 5.8.3 to prevent backwards compatibility breaking changes. From version 5.8.3 rolling updates are supported.
A new API for deprovisioning user data can be enabled by configuring the following INI settings:
engineApi.features.deprovision = 1
engineApi.users.deprovision.username = "..."
engineApi.users.deprovision.password = "..."
Please note that these settings for now are mandatory! For Engine to work correctly specify a username and password.
The consent screen can now show an IdP provided message. To render this information correctly two new configuration parameters where introduced:
defaults.logo
The logo of the suite engine block is configured for. This logo isrendered in the NameID section on the consent screen but might be used in other situations.openconext.supportUrlNameId
A link to the support page giving more information on the NameID strategies available in the OpenConext platform.
All references to Janus have been removed from the EngineBlock codebase and has been substituted with metadata push. This also includes the configuration settings. Be sure to set the correct values in the INI settings for the push mechanism to work.
; old
engineApi.users.janus.username = "..."
engineApi.users.janus.password = "..."
; new
engineApi.users.metadataPush.username = "..."
engineApi.users.metadataPush.password = "..."
The attribute aggregation was enabled/disabled explicitly in previous releases of Engineblock. This value was based on a feature flag set in the metadata repository (Manage). This is no longer required as we can distill whether or not this feature should be enabled based on the existence (or lack of) source indications on the attribute values.
This changes means that a column was dropped from the sso_provider_roles_eb5
schema. Running the Version20180724175453
migration takes care of this. Leaving the column in the database should not prove problematic for the time being.
The use of a RequesterId can now be enforced on a trusted proxy. To do so, a new metadata flag can be set in the metadata repository (Manage).
This change means that a column was added from the sso_provider_roles_eb5
schema. Running the Version20180804090135
migration takes care of this.
Doctrine Migrations is now the only tool used to manage database schema changes. If your deployment scripts call
bin/migrate
or bin/dbpatch.php
, those calls can be removed.
NOTE: Upgrade from EB4.x is no longer supported. Upgrade to EB<=5.6 BEFORE upgrading to 5.7.
https://www.pivotaltracker.com/story/show/148324779
The Push API is the only supported method of provisioning metadata to EngineBlock. EngineBlock always reads metadata
from the sso_provider_roles_eb5
table. This means INI configuration regarding metadata repositories can be removed
from your configuration:
metadataRepository.*
metadataRepositories[*]
serviceRegistry.*
If those options are not removed from the configuration, they will be ignored.
https://www.pivotaltracker.com/story/show/154839908
Metadata pushed to EngineBlock in earlier versions (EB<5.7) is not compatible with this version. A metadata push is required after upgrading to EB 5.7.
The INI setting 'hostname' was previously optional. EngineBlock used the Host header from the request (HTTP_HOST) when omitted. Starting from EB5.7, the hostname setting is required and must be present in application.ini or /etc/openconext/engineblock.ini.
Make sure your INI file contains the hostname setting before deploying EB5.7.
hostname = engine.example.org
For the development VM:
hostname = engine.vm.openconext.org
For the demo environment:
hostname = engine.demo.openconext.org
The following INI settings are inherited from EB4.x and were never used in EB5.x. They can be safely removed from configuration files and will be ignored otherwise.
auth.simplesamlphp.*
engine.simplesamlphp.*
defaults.subheader
defaults.layout
logger.factory
logger.conf.handlers
logger.conf.handler.syslog.factory
logger.conf.handler.syslog.conf.formatter.factory
logger.conf.handler.fingers_crossed.factory
logger.conf.handler.fingers_crossed.conf.handler
logger.conf.handler.fingers_crossed.conf.activation_strategy.factory
logger.conf.processor.request_id.factory
logger.conf.processor.session_id.factory
error.module
error.controller
error.action
symfony.logPath
symfony.cachePath
A new INI parameter openconext.supportUrl
has been added. It is currently only used on the 'about OpenConext' slide-in
on the consent page.
It defaults to "https://www.example.org/support" and should contain a URL to a support page for users to read more about the platform.
All .phtml templates (Zend_Layout) have been rewritten to Twig templates. Any custom theme should be rewritten to utilize Twig templates.
https://www.pivotaltracker.com/story/show/155358923
Also see the upgraded theme wiki page.
The following files have been renamed:
- languages/nl.php -> languages/messages.nl.php
- languages/en.php -> languages/messages.en.php
The placeholder format for translations has been changed from sprintf-style (%1$s) to symfony-style (%named%).
In order to make the default translations less specific to deployment in the educational world, and less specific to SURFconext, all occurrences of SURFconext and the noun 'institution' are configurable. Instead of translations like:
'More information about SURFconext'
'Find your institution'
We now write the translations as:
'More information about %suiteName%
'Find your %organisationNoun%
The values of suiteName and organisationNoun are themselves translations, defaulting to:
'suite_name' => 'OpenConext',
'organisation_noun' => 'organisation',
It is possible to override all translations by placing a overrides.en.php or overrides.nl.php inside the languages folder. For SURFconext, on deployment the two files will have to be added containing at least:
<?php
return [
'suite_name' => 'SURFconext,
'organisation_noun' => 'institution,
];
Engineblock's Consent API, which is used by OpenConext-Profile no longer exposes the most recent date of consent given (last use on). Instead, it offers only the first consent given (consent given on).
The bulk of the changes between the 4.x and 5.x releases are non-functional. A start has been made to migrate the application from the custom framework to Symfony. This means that the 4.x application is wrapped within a new symfony based application that will eventually replace the current application, while keeping functionality intact.
The Profile component has been replaced by a new application, OpenConext-Profile. This can be deployed using
the OpenConext-Deploy repository (at the moment of writing, using the engineblock5-centos7
branch).
The profile functionality has been completely removed from EngineBlock.
In the 4.x range, the entrypoint for the EngineBlock application was the www
folder, with per component (api
,
authentication
and profile
a different folder containing an index.php
. In the new setup, with Profile removed,
a single entrypoint is used: web/app.php
(in development web/app_dev.php
). Please ensure that the virtual hosts or
server blocks are updated accordingly. An example can be found here.
As of version 5.0.0-alpha4 the minimum PHP version requirement has been upped to 5.6. This to ensure using a safe and supported version of PHP to run the platform on. This is a strict requirement - components may no longer work correctly with a version below PHP 5.6
The custom UUID implementation has been replaced with Ramsey UUID. If you used the Surfnet_Zend_Uuid
anywhere
please replace this with \Ramsey\Uuid\Uuid
.
Configuration file location was moved from /etc/surfconext/engineblock.ini
to /etc/openconext/engineblock.ini
All other references to surfconext
have been replaced with openconext
. Using OpenConext-Deploy should
help with any issues that could possibly stem from this change.
Part of the configuration is now also used in .yml
configuration. In order to have access to the required
parameters when booting, app/config/ini_parameter.yml
must be present. This file is created automatically
by composer during installation, but can be recreated manually using bin/composer/dump-required-ini-params.sh
.
Also, please ensure that after unpacking a release, before using the installation, composer prepare-env --env=prod
is run so that all requirements for a fully functioning application are met (correct configuration, a warmed cache, etc)
subjectIdAttribute
Due to the migration from LDAP to database storage for registered users, the configurationsubjectIdAttribute
has been removed. The equivalent of thecollabpersonid
configuration value will now always be used.
Several feature toggles have been added, and several users can now be configured.
engineblock.feature.ldap_integration
see below for more informationengineApi.features.metadataPush
controls the availability of the metadata push api. Setting this to1
will enable it.
Only available for the user with the roleROLE_API_USER_JANUS
- can be configured through theapi.users.janus.username
andapi.users.janus.password
settings, which must authenticate using HTTP Basic AuthenticationengineApi.features.consentListing
controls the availability of the consent listing API. Setting this to1
will enable it.
Only available for the user with the roleROLE_API_USER_PROFILE
- can be configured through theapi.users.profile.username
andapi.users.profile.password
settings, which must authenticate using HTTP Basic AuthenticationengineApi.features.metadatApi
controls the availability of the metadata read API. Setting this to1
will enable it.
Only available for the user with the roleROLE_API_USER_PROFILE
- can be configured through theapi.users.profile.username
andapi.users.profile.password
settings, which must authenticate using HTTP Basic Authentication
For Attribute Aggregation usage, which can be enabled per service provider by setting the attributeAggregationRequired
configuration value to true, the following configuration has been added:
attribute_aggregation.base_url
the base_url of the attribute aggregation serviceattribute.aggregation.username
the username used to authenticate with the attribute aggregation serviceattribute.aggregation.password
the password used to authenticate with the attribute aggregation service
The Database configuration changed from master/slave to single host to allow for multi-master clustering. This means the .ini
configuration has changed from (this will be ignored now):
database.master1.dsn = "mysql:host=123.456.78.90;port=3307;dbname=engineblock"
database.master1.password = password
database.master1.user = username
database.slave1.dsn = "mysql:host=123.456.78.91;port=3307;dbname=engineblock"
database.slave1.password = password
database.slave1.user = username
database.masters[] = master1
database.slaves[] = slave1
To:
database.host = 123.456.78.90
database.port = 3307
database.user = username
database.password = password
database.dbname = engineblock
When a master/slave setup is still required, this can be configured by creating a config_local.yml
in app/config
.
This file will be loaded automatically if present and will allow overriding any configuration present. Do note that in
order to be able to load the file app/console cache:clear --env={current_env_as_in_vhost}
must be executed once.
More information on how to configure Doctrine can be found in the bundle documentation and the configuration
reference documentation. Before considering using a master/slave setup, please review this documentation
as to when a master or slave is used for a connection.
EngineBlock 4.x tracks logins in the log_login table of the database. In EngineBlock 5.0 this has been
replaced wih logging to syslog. This to reduce write load on the database. The log statements are written
to syslog using the specific ident EBAUTH
as can be seen in the app/config/logging.yml
file.
For each login a message akin to the following is being logged:
Apr 1 11:49:00 apps EBAUTH[4861]: {"channel":"authentication","level":"INFO","message":"login granted","context":{"login_stamp":"2016-04-01T11:49:00+02:00","user_id":"urn:collab:person:engine-test-stand.openconext.org:test145950413313365","sp_entity_id":"https:\/\/engine.vm.openconext.org\/functional-testing\/No%20ARP\/metadata","idp_entity_id":"https:\/\/engine.vm.openconext.org\/functional-testing\/TestIdp\/metadata","key_id":null},"extra":{"session_id":"8zxzInsnhMWUOLJpXyz9uxX2TCa","request_id":"56fe440bc31ea"}}
The users are now stored in the database, and optionally also in the LDAP (to facilitate a graceful rollover). You are advised to perform a migration as soon as possible, as LDAP functionality is scheduled to be removed in the coming releases.