Ory Kratos, Ory Polis v26.3.16 released

Ory Kratos

Phone number validation now uses current numbering-plan data

Ory validates phone numbers against the current libphonenumber dataset. Numbers in ranges assigned since the previous dataset now validate on format: tel identity traits and on SMS identifiers, where they were previously rejected.

Phone numbers typed with any Unicode decimal digits, such as Devanagari or Bengali, now normalize to E.164. Previously only Arabic-Indic and fullwidth digits did.

Breaking changes

The same refresh removes ranges that national regulators have withdrawn:

CountryWithdrawn rangeSyria+963 91x, +963 92x, +963 97xSlovenia+386 49xMonaco+377 49x, +377 049xFaroe Islands+298 88xVietnam+84 80xxNorway / Svalbard+47 4536xGeorgia+995 5441x

Syria also gains the +963 90x range.

For identities that already hold a number in a withdrawn range:

• Sign-in, account recovery, and verification work only when the number is entered without spaces or dashes: +38649xxxxxx, not +386 49x xxx. Formatted input fails with the generic invalid-credentials error, so the cause is not visible to the user.

• New registrations with such a number are rejected.

• Password changes and other settings updates are rejected while the stored number remains in a withdrawn range, because the identity is validated against the schema on every settings write.

Check your identities for the prefixes above and ask affected users to update to a currently assigned number. The withdrawn ranges are no longer assignable, so those numbers may stop receiving SMS regardless of Ory.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Polis

Concurrent SSO connection updates no longer fail with an internal server error

Updating several SSO connections of the same tenant at the same time could fail with HTTP 500. On CockroachDB and YugabyteDB, which run every transaction at serializable isolation, those writes touch the same records and the database rolls one of them back with a retryable conflict. Polis reported the conflict as an error instead of replaying the transaction, so the caller saw a failure for a condition the database expects the client to absorb. A caller that retried the request made the next conflict more likely.

Polis now replays a write that loses such a conflict, a bounded number of times and with a randomized delay between attempts. Where the write is an update that was built from an earlier read, such as a change to an SSO connection, the replay reads the record again first, so it does not write back over a change another request made in between. MySQL, MariaDB and PlanetScale report a deadlocked transaction the same way and are replayed too. There is nothing to configure.

This reduces but does not remove the chance of one update overwriting another: the database only reports a conflict when the two writes overlap in time.

Updating an SSO connection that does not exist now answers 404 with SSO connection not found, where it previously failed with an internal error. A replay reaches the same answer when the request it lost the conflict to was the one that deleted the connection.

On the Ory Network this failure reached project updates that changed SAML providers, which now succeed.

Polis can now run in FIPS 140-3 mode

Every cryptographic operation in Polis now goes through Node's node:crypto/WebCrypto rather than pure-JavaScript implementations, and Polis gains a preview container image, polis-oel-fips, that runs with an OpenSSL FIPS provider active so that only FIPS-approved algorithms are available.

The preview image is built and security-scanned on every release, but it is not yet published to the enterprise registry or Cloudsmith, and the release pipeline's runtime tests do not yet cover it. Contact us if you want to evaluate it.

Existing deployments are unaffected. If you do not run the FIPS image, nothing about your data or your integrations changes: datastore keys, connection clientIDs, setup-link IDs, identity federation app IDs, the SP entity ID, and the idHash claim all keep their current values. They are still derived with RIPEMD-160, which now comes from OpenSSL instead of a JavaScript package — the same digest, byte for byte.

What changes if you run the FIPS image:

• Datastore keys and the IDs derived from them use SHA-256, because RIPEMD-160 is not FIPS-approved at any implementation. They are 64 hex characters rather than 40, so connection clientIDs, setup-link IDs, identity federation app IDs and the idHash claim are longer under the FIPS image than under the standard one.

• A FIPS datastore and a non-FIPS datastore are not interchangeable. The two digests produce different keys, so a database written by one cannot be read by the other. Pick one mode per deployment. Moving an existing deployment into (or out of) FIPS mode requires re-keying your data; contact us for the migration path. Polis logs which digest is active at startup so you can confirm what a running process is using.

• A SAML signing certificate that Polis generated for itself is stored under a digest-derived key, so it is re-keyed along with everything else and identity providers holding the old certificate must be updated. Deployments that set PUBLIC_KEY/PRIVATE_KEY are unaffected — an operator-supplied certificate never goes through the datastore.

• DB_TYPE=mssql is refused, both at startup and by the database migration job: its NTLM authentication depends on MD4, which FIPS does not permit. It is the only database Polis supports that FIPS rules out — postgres, cockroachdb, yugabytedb, mysql, mariadb and sqlite all work, as do the non-SQL engines (mongo, redis, dynamodb, planetscale).

• An IdP that still signs SAML responses with RSA-SHA1, or encrypts assertions with RSA-PKCS#1 v1.5 key transport or 3DES, will fail verification. Reconfigure it for RSA-SHA256, RSA-OAEP, and AES. Polis now reports these failures with a message naming the likely cause and the IdP-side fix instead of the raw OpenSSL error.

• Polis warns at startup, without blocking, when DB_ENCRYPTION_KEY is unset or when it is using an auto-generated SAML signing certificate.

Applies to both images:

• Newly generated default SAML signing certificates use RSA-3072 keys (previously RSA-2048), and are created through WebCrypto. Existing certificates are unchanged and keep verifying.

A note on what the FIPS image is: its cryptography is confined to FIPS-approved algorithms and it provably runs in FIPS mode, independent of the host. The FIPS provider is compiled from upstream OpenSSL source, so it is not a CMVP-validated module and this image should not be described as FIPS 140-3 validated.

See what a webhook delivery carried without opening it

The Admin Portal listed a directory's webhook events by endpoint, status code and time. Every row carried the endpoint it was sent to and nothing about its contents, so finding the delivery for one person meant opening events one at a time to read their JSON.

A row now names the event types the delivery carried and who or what they applied to: a user by email address, a group by name, a membership change by both. A delivery that carried a batch of events reports how many users and groups it touched rather than naming them. The time a delivery was sent is a link to it.

The event page lists each event in the delivery beside its subject and shows the payload your endpoint received, with a button to copy it. It previously showed the whole stored record; the fields that wrapped the payload are now listed above it rather than buried in the JSON.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Network, Ory Hydra, Ory Keto, Ory Oathkeeper, Ory Elements, and Ory Terraform

No significant changes in this release.