Skip to main content

v26.3.15

v26.3.15​

DynamoDB deployments now honor the page limit when listing records​

When DB_ENGINE is dynamodb, endpoints that list records by an index returned every matching record in one response and ignored the requested page size. They now return at most DB_PAGE_LIMIT records per call, which matches every other database engine.

DynamoDB cannot skip records, so pageOffset is ignored on this engine. When you page through connections, directory users or groups, or SSO traces with the management API, read the pageToken from the response and pass it back to fetch the next page.

SCIM is the exception, because it has no page token. The SCIM endpoints an identity provider calls page with startIndex, which DynamoDB ignores, so on this engine an identity provider reads the first DB_PAGE_LIMIT users or groups of a directory and cannot reach the rest. Do not run directory sync on DynamoDB with directories larger than DB_PAGE_LIMIT.

Index rows are also written in batches now, and any row DynamoDB reports as unwritten is retried. Under heavy write throttling a record could previously be saved but stay unreachable through one of the indexes that point at it.

Listing SSO connections now returns all of them​

Reading the SSO connections for a tenant and product returned only as many as a single database read yields, which DB_PAGE_LIMIT caps and defaults to 50. A tenant with more connections than that saw a short list with nothing to indicate records were missing, and the same limit applied when reading connections for several tenants at once, when filtering by strategy, and when looking up connections by identity provider entity ID.

All of these now read through to the end of the list. If you have more connections than DB_PAGE_LIMIT under one tenant and product, expect the list to be longer than before.

Support IdP-initiated SAML login​

Enterprise users can now start a login from their identity provider's app launcher (for example the Okta or Azure AD dashboard) and land in your application with a valid Ory session.

When an identity provider posts an unsolicited SAML response, Ory Polis validates it and redirects the browser to a new Kratos entry point with a single-use authorization code. Kratos starts a regular SP-initiated login flow — with the usual state, CSRF, and PKCE protections — and forwards the code as a code_hint to the Polis authorize endpoint. Polis consumes the hint and completes the flow immediately, without a second round-trip to the identity provider.

Standalone Ory Polis already supports IdP-initiated SAML login through its direct redemption flow. This change adds the Kratos side: an entry point that folds the unsolicited response into a regular SP-initiated Kratos login, wired together with Polis through the code_hint.

To enable it on Ory Network, turn on the "IdP-initiated login" toggle in the SAML provider settings in Ory Console. Ory then points the SAML connection's default redirect URL at the entry point automatically.

To enable it on a self-hosted Ory deployment that runs Kratos and Polis together:

  1. Set idp_initiated_login_enabled: true on the SAML (jackson) provider in your Kratos configuration.
  2. Point the Polis SAML connection's defaultRedirectUrl at https://<your-project>/self-service/methods/saml/idp-initiated/<provider>.
  3. Run Polis with IDP_ENABLED=true.

IDP_ENABLED is the deployment-wide switch. A connection follows it unless it sets idpInitiatedLoginEnabled explicitly: true always allows IdP-initiated login for that connection and false always blocks it. On Ory Network the switch stays off and the Console toggle sets the per-connection flag, so no deployment-wide change is needed.

The code hint is single use, expires with the code store TTL, and is only valid for the exact connection it was issued for. SP-initiated codes cannot be used as hints. If a hint is invalid or already consumed, the user is sent through the regular SP-initiated redirect instead — usually completing silently against the identity provider's existing session.