Page Comparison

...

• User verification step (optional). The external authentication methods shown in this step are configured in a protection configuration and it can be selected with registration. <index_number>.verification.protection.configuration key.
• Entering user information (obligatory). The collected information and the obligatory information are configurable. This can be set with registration. <index_number>.userinfo.fields and registration. <index_number>.userinfo.optional key.
• Multiple steps can be configured by adding fields of each step inside curly brackets. For example, registration.1.userinfo.fields = {customid, email}, {firstname, surname, mobile, acceptTerms}
• Custom attributes can be created by giving them names and adding descriptions to messages_xx.properties. For example, registration.1.userinfo.fields = firstname, surname, testikentta
• The system also supports the option to check that the user has a valid customership in the company customer information system. These are set with keys that start with registration.<index_number>.backend.
• Activation of authentication methods (optional). With this step you can, for example, force the user to print out a list of one time passwords.
  Activation step is shown if there are methods set with registration.<index_number>.methods key that are defined visible. The activated authentication methods are configurable and the desired authentication methods can be set as obligatory. Obligatory authentication methods must be activated before the user can proceed.

• Information summary (obligatoryoptional). This step only shows the user the entered information and asks the user to check the information before proceeding. This step requires no configuration.

...

registration.1.userinfo.disabled = ssn

registration.N.summary.enabled

This property defines if the summary step is present in the registration wizard. There are two possible values:

...

This property defines all the fields shown in the summary step and confirmation steps of the registration wizard.

...

• path: The entity name of the organization e.g. "path" : "Customers/${customerid}". This key supports user input notation described above. If no customerid or similar attribute uniquely defining the organization in the registration can be used a special attribute organization.generatedTechnicalName is available as described above.
• name: The friendly name of the organization created e.g. "name" : "Customer ${customerid}". If not defined the last part of the entity name (relative name) is used. This key supports user input notation described above.
• organizationtype: The organization type of the user organization e.g. "organizationtype" : "customer". This key is mandatory.
• storeattributes: If set to true the organization attributes provided during the registration will be stored in the respective organization. If only certain attributes should be stored then the names of the respective attributes can be given in a JSON array object, e.g. "storeattributes" : [ "orgattribute1", "orgattribute2" ].

Additional organizations can be defined with the same key set found above as the user organizations. In addition following keys are definable for additional organizations:

...

The JSON notation of the user organization must at minimum contain the key path which defines the entity path of the organization where the user is stored.

...

If you want to grant the user roles from the organization where the user is being registered to, then you can refer to this organization with the variable ${user_organization} and append the desired role after this, separated by a slash character. Note that these roles must already be configured to the target organization.

...

In the example above, the path key defines the path of the role and the approval key defines whether the role requires a separate approval process. If the value of approval is set to true, the role requires a separate approval process and will not automatically be approved when the user registration is approved. The user registration will, however, result in a functional user account, but the role will not be available until it has been separately approved. If the approval key is set with a false attribute, or omitted entirely, the role will be in effect when the user registration itself is approved.

...