Udgivelser

Adds granular controls for the External Password API so you can independently enable calls to the Validation and Notification endpoints on specific events (login and password change). Previously, each endpoint could only be enabled or disabled globally.

New features

• External Password API - Validation endpoint: per-event toggles
  You can now enable or disable calling the Validation endpoint on:

  • User login
  • Password change

• External Password API - Notification endpoint: per-event toggles
  You can now enable or disable calling the Notification endpoint on:

  • User login
  • Password change

• Previous behavior
  Before this change, it was only possible to enable or disable each of the two endpoints in general, without controlling when they were invoked.

Resolves an issue where the login hint was not propagated or displayed on the login page, preventing expected prefill behavior and slightly increasing user friction.

Bugs fixed

• Login hint not displayed
  Fixed a defect where a provided login hint was neither passed from the login page nor shown to the user on the login page. The value is now correctly carried forward and rendered, improving usability and reducing input errors.

Fixes an issue in bulk user uploads where the "change password on next login" flag was not applied when a user's password was provided as a hash. This ensures consistent post‑provisioning security behavior regardless of whether plaintext passwords or pre‑hashed passwords are uploaded.

Bugs fixed

• Bulk upload: missing "change password on next login" flag for hashed passwords
  Previously, when users were imported in bulk with a password hash (rather than a plaintext password), the system failed to mark them for a required password change on next login (when that behavior was expected/configured). The logic now applies the flag consistently, ensuring security policies are enforced uniformly for all imported users.

This release expands SAML 2.0 boolean value handling to accept all XML Schema–compliant boolean literals (true, false, 1, 0) and improves startup behavior by executing the FoxIDs Control seeding process immediately at application start rather than deferring it until the first HTTP request.

New features

• Expanded SAML 2.0 boolean handling
  Boolean attributes in SAML 2.0 messages now accept the full set of XML Schema boolean literals: true, false, 1, and 0 (previously only true and false). This improves compatibility with identity providers or tooling that serialize boolean values numerically.

  Rationale and specification references:
  The SAML 2.0 specification examples typically show the string values "true" and "false" (for example, the NameIDPolicy AllowCreate attribute). However, the SAML protocol schema (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) defines such attributes with the XML Schema boolean type. According to the W3C XML Schema Datatypes specification (https://www.w3.org/TR/xmlschema11-2/#boolean), valid lexical representations for a boolean are true, false, 1, and 0. Supporting all four forms ensures full standards compliance and broader interoperability.

• Immediate seeding on application startup
  The FoxIDs Control application now performs its seeding process during startup instead of waiting for the first incoming HTTP request. This:

  • Eliminates the initial user-facing delay on the first request
  • Surfaces configuration or data initialization errors earlier in the deployment lifecycle

This update enhances two‑factor (2FA/MFA) usability by returning clearer error message, streamlines user creation by treating empty identifier fields like null, and improves development workflows by adding a disable password hashes calculation flag in the Seed Tool.

New features

• Improved 2FA/MFA error handling
  When a user is required to do SMS / email two‑factor authentication without at least an email address / phone number, the system now returns a clear error message explaining what must be added before 2FA can succeed.

• User API: empty identifiers treated like null on user creation
  The Create User API now accepts empty string ("") values for identifier fields and treats them the same as null. This simplifies client form handling and reduces conditional logic.

• Seed Tool: calculate password hash flag
  Added a disable password hashes calculation flag to the Seed Tool making it possible to not automatically calculates password hashes during seeding.

This release adds support for external password validation and notifications, enforces password checks at login, and improves bulk user upload capabilities.

New features

• External password validation and notification API
  • An API endpoint for validating passwords against external policies and sending notifications when needed.
• Password checks on every login
  • Password validation is performed on each login attempt to ensure compliance with current policies.
• Bulk user upload with password hash support
  • You can now upload users in bulk and include password hashes where required.

Bulk upload limits

• Without a password (no password field provided): 1,000 users per request
• With a plaintext password: 100 users per request
• With a password hash: 1,000 users per request

Bugs fixed

• Users not found on PostgreSQL
  • Fixed an issue where user lookups could fail when the application used PostgreSQL as the database.

• Support Telia SMS gateway.
• Possible to configure SMS gateways (Gateway API, Smstools and Telia SMS Gateway) in the environment in the Control Clients Settings tap.
• Support to use the user’s phone_number and email claims for MFA/two-factor if there is not phone or email user identifiers defined on the user.
• Can register two-factor app with a phone user identifier configured. Before only supporting the email and username user identifiers.
• General Nuget package update including PgKeyValueDB v1.4.0.
• Developer support for Visual Studio Code.

• Add Swagger/Open API V2 in Conrtol API on api/swagger/v2/swagger.json and online on https://control.foxids.com/api/swagger/v2/swagger.json where the variables in the path is changed to {tenant_name}/{track_name} to follow the Swagger/Open API standard.
• Swagger/Open API V1 is still available in Conrtol API on api/swagger/v1/swagger.json and online on https://control.foxids.com/api/swagger/v1/swagger.json with the old variable format [tenant_name]/[track_name].
• Swagger UI is part of the Control API on api/swagger and available online on https://control.foxids.com/api/swagger.
• Swagger Open API version updated to 3.0.4.
• Improve validation of AllowUpPartyNames and AllowUpParties in Conrtol API.
• Improve token request error handling.

Bugs fixed:

• Conrtol API enums in ExternalConnectType?, ClaimTransformTasks? and PartyTypes? miss nullable declaration in Swagger document.

Small breaking API change

• Breaking change of how to handle secret updates in client transforms external API claims and extended UI API.
  • You receive the secret in both the Secret and SecretLoaded attribute. The secret is shortened to the first 3 characters of the secret suffixed with ..., if the secret is longer then 20 characters.
  • To not change the secret on update return the received secret / shortened secret in both the Secret and SecretLoaded attribute.
  • To change the secret on update set the new secret in the Secret attribute and return the received secret / shortened secret in the SecretLoaded attribute.
  • To deleted the secret on update return an empty Secret attribute and the received secret / shortened secret in the SecretLoaded attribute.

Bugs fixed:

• Token request with basic auth client credentials require client_id, should be optional.

• Run first-level claim transform after session create / update in Login and External Login authentication methods.
• Possible to collapse Extended UI configuration in Control Client.

Bugs fixed:

• Unable to decrypt SAML 2.0 authn response with secondary certificate because of incorrect exception handling.