The reg-app is a JEE Application using the JEE8 standard. In order to run it needs a JEE8 capable application server. It is tested against the Wildfly (version at least 17.0.1) application server. It may run on other application servers, but this is not tested and not supported. The application can be run in a docker environment, or run in application server as enterprise archive (ear). Running the application in a docker environment ist the easeiest way to get started and running.
Or:
- Building the application
- Preparing the database
- Install/Configure the Wildfly application server
- Deploying the application
After successful installation of the application, you can start with the configuration section.
Update
In order to update the application, you simply have to undeploy the old version, and deploy the new version. Most of the database schema updates are handled automatically via Hibernate at the moment. This behavior may change in the future. Sometimes it is not possible to update the schema because of database constraints. In this case the version is listed below.
Update to version 1.4.0
User reconciliation is not done automatically anymore. It is now event driven. To get the previous behavior back, follow the instructions in the section User Reconciliation.
Update to version 2.3.0
There are some changes in the datamodel from version 1 to version 2. To reflect these changes the table "group_store" has to be extended with the column "DTYPE". For existing entries the DTYPE has to be set to "HomeOrgGroupEntity". The column has to be "NOT NULL". With the application server stopped the SQL commands for MS SQL are for example:
ALTER TABLE group_store ADD DTYPE varchar(31);
UPDATE group_store SET "DTYPE" = 'HomeOrgGroupEntity';
ALTER TABLE group_store ALTER COLUMN DTYPE varchar(31) NOT NULL;The application behaves differently regarding groups now. It should be possible to have same group names and gidNumbers for different groups, depending on the service, the group is connected with. To make this possible, you have to remove all unique constraints (if set) on "gid_number" and "group_name" in the table "group_store".
After starting the application server again, with the new version ear, some new tables will be created. The tables "user_event" and "service_event" are no longer used. The data contained in there is now processed from the table "event_table". To migrate the existing data, you could use the following SQL statements (MS SQL specific):
INSERT INTO event_table (DTYPE, id, created_at, updated_at, [version], eventType, jobClass_id)
SELECT 'UserEventEntity', id, created_at, updated_at, [version], eventType, jobClass_id
FROM user_event;
INSERT INTO event_table (DTYPE, id, created_at, updated_at, [version], eventType, jobClass_id, service_id)
SELECT 'ServiceEventEntity', id, created_at, updated_at, [version], eventType, jobClass_id, [service_id]
FROM service_event;In the new version, all groups have to be connected to a service, in order to be used there. All existing groups are not automatically connected, only newly created groups will be. To connect the existing groups, visit the Admin menue -> All groups. Click on the button "Add all group flags" and watch the logfile from the application server. After all groups are connected, click on the button "Fire group change event" and again watch the logfile. The procedure will take some time, depending on the number of groups in the system. After the procedure, there sould be no entry in the "service_group_flag" table with the "status" "DITRY". Also you can expect one entry per group and group capable service in this table.
Group reconciliation is not done automatically anymore. It is now event driven. To get the previous behavior back, follow the instructions in the section Group Reconciliation.
Update to version 2.4.0
In this version the connection between Federations and IDPs is converted from 1:n to n:m. To reflect this change you can drop the column federation_id in the database table idpmetadata, after the new version is deployed. Don't forget to delete the foreign key constraint as well. You also have to reconnect the idps with their federation. In order to do this, you can poll a federation, or wait until this is done automatically. Please also delete unique constraint on the columns entity_id and federation_metadata_url on the table federation. These constraints could block your desired configuration and are not necessary.
ALTER TABLE [idpmetadata]
DROP COLUMN [federation_id]Update to version 2.6.1
ALTER TABLE usertable ADD COLUMN dtype character varying(31);
UPDATE usertable SET dtype = 'SamlUserEntity';
ALTER TABLE usertable ALTER COLUMN dtype SET NOT NULL;In this version, the object UserEntity changed to SamlUserEntity. If you are using this object in your rules, you need to change them. You can batch search and replace all occurrences in the admin -> rules menue. Enter UserEntity in the regex field and SamlUserEntity in the replace field and click the button once. Then check your rules and your log file for errors.
Update to version 2.7.5
In this version the property persistentIdpId was removed from SamlUserEntity. Please check your rules, if you are using this property. Change persistentIdpId to idp.entityId. Do this, before upgrading.