Ory Network, Ory Hydra, Ory Kratos, Ory Keto, Ory Oathkeeper, Ory Polis v26.4.14 released

Ory Network

SAML providers store their SP entity ID

Each SAML provider now has one SP entity ID, the audience its IdP sends, in sp_entity_id, on both the default and the native engine.

• In Ory Network, each SAML provider stores its SP entity ID, and you can set it to your own value. A save that leaves it out keeps the stored value, so switching a provider between engines, moving it to another organization, changing audience_override_base_url, or removing proxy_saml_audience_override no longer changes the audience your IdP must send. A new or changed proxy_saml_audience_override still sets it. A native provider no longer has an sp_entity_id_override field; set sp_entity_id instead. Providers that share one SAML connection on the shared ACS URL must have the same sp_entity_id. The identity configuration shows the stored sp_entity_id of each provider, and the acs_url of a provider on the default engine with its own ACS URL, which a save doesn't change.

• In Ory Enterprise License (OEL) deployments of Ory Kratos Identities, the native SAML engine reads the SP entity ID of a provider from sp_entity_id. sp_entity_id_override still works but is deprecated.

This is now available on Ory Network and for the Ory Enterprise License.

Ory Hydra

Writing a key keeps its trust relationships

Writing a key with PUT /admin/keys/{set}/{kid} or PUT /admin/keys/{set} deleted every trust relationship for the JWT authorization grant that used the key, even when the key didn't change. Token requests with the urn:ietf:params:oauth:grant-type:jwt-bearer grant type that relied on such a trust relationship then failed with invalid_grant. Ory Hydra Authorization now keeps these trust relationships. When you write a different key under the same key ID, its trust relationships verify assertions with the new key. A key that you leave out of PUT /admin/keys/{set} is still deleted, together with its trust relationships.

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

Ory Kratos

Check sessions against risk rules

Ory Kratos can now evaluate risk rules every time it checks a session at /sessions/whoami or /sessions/whoami-jwt/{template}. Configure up to 5 rules under session.whoami.rules. Each rule is a CEL condition over the session and the request, including the client IP address, its reputation labels, and its location, and an action: require_aal2 requires a second factor for the rest of the session, and revoke revokes the session.

SAML providers store their SP entity ID

Each SAML provider now has one SP entity ID, the audience its IdP sends, in sp_entity_id, on both the default and the native engine.

• In Ory Network, each SAML provider stores its SP entity ID, and you can set it to your own value. A save that leaves it out keeps the stored value, so switching a provider between engines, moving it to another organization, changing audience_override_base_url, or removing proxy_saml_audience_override no longer changes the audience your IdP must send. A new or changed proxy_saml_audience_override still sets it. A native provider no longer has an sp_entity_id_override field; set sp_entity_id instead. Providers that share one SAML connection on the shared ACS URL must have the same sp_entity_id. The identity configuration shows the stored sp_entity_id of each provider, and the acs_url of a provider on the default engine with its own ACS URL, which a save doesn't change.

• In Ory Enterprise License (OEL) deployments of Ory Kratos Identities, the native SAML engine reads the SP entity ID of a provider from sp_entity_id. sp_entity_id_override still works but is deprecated.

This is now available on Ory Network and for the Ory Enterprise License.

Ory Keto

Ory Keto and Ory Oathkeeper verify TLS with a built-in root certificate bundle

The Ory Enterprise License (OEL) images of Ory Keto Permissions and Ory Oathkeeper IAM Proxy now verify outbound TLS connections against Mozilla's root certificate authorities (CAs), which are built into the binary. Ory Kratos Identities, Ory Hydra Authorization, and Ory Talos Secure API Keys already work this way. The services no longer read the CA bundle of the container image, and they ignore a bundle in SSL_CERT_FILE or SSL_CERT_DIR by default.

Breaking changes

If Ory Keto Permissions or Ory Oathkeeper IAM Proxy calls an endpoint that uses a certificate from a private CA, the call now fails with x509: certificate signed by unknown authority. For Ory Oathkeeper IAM Proxy, this includes token introspection, JWKS, and remote authorizer endpoints. To keep trusting your private CA, set GODEBUG=x509usefallbackroots=0 together with SSL_CERT_FILE or SSL_CERT_DIR. Your bundle must also contain the public root CAs that the service needs. See Trust a private certificate authority.

This is now available for the Ory Enterprise License.

Ory Oathkeeper

Ory Keto and Ory Oathkeeper verify TLS with a built-in root certificate bundle

The Ory Enterprise License (OEL) images of Ory Keto Permissions and Ory Oathkeeper IAM Proxy now verify outbound TLS connections against Mozilla's root certificate authorities (CAs), which are built into the binary. Ory Kratos Identities, Ory Hydra Authorization, and Ory Talos Secure API Keys already work this way. The services no longer read the CA bundle of the container image, and they ignore a bundle in SSL_CERT_FILE or SSL_CERT_DIR by default.

Breaking changes

If Ory Keto Permissions or Ory Oathkeeper IAM Proxy calls an endpoint that uses a certificate from a private CA, the call now fails with x509: certificate signed by unknown authority. For Ory Oathkeeper IAM Proxy, this includes token introspection, JWKS, and remote authorizer endpoints. To keep trusting your private CA, set GODEBUG=x509usefallbackroots=0 together with SSL_CERT_FILE or SSL_CERT_DIR. Your bundle must also contain the public root CAs that the service needs. See Trust a private certificate authority.

This is now available for the Ory Enterprise License.

Ory Polis

Identity federation apps must send their own credentials to exchange a code

The token endpoint now requires an OIDC identity federation app's own client_id and client_secret to exchange an authorization code issued for that app, whether or not the login used PKCE. The credentials can be sent in the request body or in an Authorization: Basic header.

Breaking changes

An exchange for a federation app's code is refused with 401 invalid_client when it sends only a code_verifier, or authenticates with other credentials, such as an SSO connection's client ID and secret or client_id=dummy with CLIENT_SECRET_VERIFIER. Configure the client to send the federation app's client ID and secret, shown on the app in the admin portal. Codes for SSO connections and other clients are not affected.

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

Ory Elements and Ory Terraform

No significant changes in this release.