Authentication with tailored user provisioning

Dynamic SSO extends standard SAML v2 authentication with dynamic provisioning. The SAML response carries additional user attributes, which Goodays maps to the rules agreed for the project. At the user's first successful login, Goodays can create an account from these attributes. At later logins, the approved rules can update the user's profile, role or access scope.

The experience remains simple for the user. The integration behind it is tailored because every organization represents roles, points of sale and organizational structures differently.

🚧

Preliminary workshop and Goodays validation required

Dynamic SSO is not a ready-made configuration and must not be assumed to be available by default. Goodays first runs a workshop with your business and IT teams, reviews the requested behavior and available identity data, and confirms whether the integration is feasible. Implementation starts only after explicit Goodays validation.

When Dynamic SSO may be relevant

Dynamic SSO is intended for situations where manual account administration would create significant operational effort: for example, a large population, frequent organizational changes or users whose access depends on structured roles and points of sale.

It also requires reliable identity data. Your organization must provide the professional email address used as the unique Goodays identifier, along with controlled business roles and maintained organizational references through the IdP.

If the requirement is primarily corporate authentication, Static SSO remains the simpler option. It can be activated first, then extended with a separate Dynamic SSO project later.

What can be provisioned

According to the model approved for the project, SAML attributes can be used to:

• Identify the user.
• Create the Goodays account when it does not yet exist.
• Update basic user information.
• Select an agreed Goodays profile or role.
• Determine which organizational levels, points of sale or groups the user can access.

Provisioning is evaluated during a successful login. Dynamic SSO is not a continuous directory-synchronization or generic SCIM service.

The preliminary workshop

The workshop brings together the client's identity specialists and the business owners who understand the expected Goodays access model. Together with Goodays, they describe:

• The target user populations and journeys.
• The identity data available through SAML.
• The business meaning of roles and organizational references.
• The expected account-creation and update behavior.
• Representative cases such as several points of sale, role changes or missing values.

This discussion is necessary because a technical value such as manager, region or point_of_sale rarely has the same meaning in two organizations.

The attribute contract

The outcome of the workshop is a shared attribute contract. It defines how the client's identity model translates into Goodays accounts and access.

The following matrix is a working template for the workshop. In the Client label column, TBC means To Be Completed: your identity team replaces it with the corresponding attribute name from your IdP. The rows retained, their exact rules and their mandatory status are then confirmed for the project.

For each retained attribute, the final contract records its business meaning, format, accepted values, source of truth and behavior when the value is absent, unknown or changes. The labels and examples above describe the expected structure; they are not a ready-to-use configuration.

Goodays validation

After the workshop, Goodays assesses whether the available attributes are sufficiently stable and unambiguous, whether the requested access model can be translated into maintainable rules, and what implementation approach is appropriate.

Goodays then confirms whether the project can proceed and defines the next delivery steps. Holding the workshop does not by itself guarantee approval.

Implementation

Once the project is approved, Goodays and your identity team configure SAML and the agreed provisioning rules. Validation uses representative users to confirm first-login creation, later updates and the resulting roles and scopes.

Production activation occurs only after both the technical journey and the expected business access have been agreed. The delivery plan is defined from the validated specification rather than from a universal setup procedure.