Getting a SAML response is not yet valid error in Grist with Authentik

Dan6erbond · January 18, 2023, 9:24am

Hello! I hope I’m not making a very obvious mistake, but while trying to setup SAML auth in Grist with my instance of Authentik, I’m getting this error after performing the log-in flow:

SAML Response is not yet valid.

My environment is configured like this, in addition to the GRIST_DOCS_MINIO_SECRET_KEY, TYPEORM_PASSWORD, GRIST_SAML_IDP_CERTS, GRIST_SAML_SP_KEY, GRIST_SAML_SP_CERT environment variables:

    "GRIST_SESSION_SECRET"        = random_id.grist_session_secret.hex
    "GRIST_SANDBOX_FLAVOR"        = "gvisor"
    "APP_HOME_URL"                = "https://${var.host}"
    "GRIST_SINGLE_ORG"            = "jenyus"
    "GRIST_DEFAULT_EMAIL"         = "moravrav@gmail.com"
    "TYPEORM_TYPE"                = "postgres"
    "TYPEORM_DATABASE"            = postgresql_database.grist.name
    "TYPEORM_USERNAME"            = postgresql_role.grist.name
    "TYPEORM_HOST"                = "postgres.default"
    "REDIS_URL"                   = "redis://${module.redis.redis_namespace_host}:6379"
    "GRIST_DOCS_MINIO_ACCESS_KEY" = minio_iam_service_account.grist.access_key
    "GRIST_DOCS_MINIO_USE_SSL"    = 1
    "GRIST_DOCS_MINIO_ENDPOINT"   = var.s3_host
    "GRIST_DOCS_MINIO_BUCKET"     = minio_s3_bucket.grist.bucket
    "GRIST_SAML_SP_HOST"          = "https://${var.host}"
    "GRIST_SAML_IDP_UNENCRYPTED"  = 1
    "GRIST_SAML_IDP_LOGIN"        = "${var.authentik_url}/application/saml/${authentik_application.grist.slug}/sso/binding/redirect/"
    "GRIST_SAML_IDP_LOGOUT"       = "${var.authentik_url}/if/session-end/${authentik_application.grist.slug}/"
    "TZ"                          = "Europe/Zurich"

I validated, that the .pem files exist and are valid. I have different certificates configured for Authentik’s signing request (self-signed certificate) and the verification certificate (new one for Grist) so it seems like it’s related to desync with container timezones maybe? Appreciate the help!

paul-grist · January 18, 2023, 2:22pm

Hmm that does sound like a clock synchronization issue. We allow 5 seconds of skew:

github.com

gristlabs/grist-core/blob/808aacdc522feeb11f74047e5bdaa5e58c49125a/app/server/lib/SamlConfig.ts#L89


      
          if (!process.env.GRIST_SAML_IDP_LOGIN) { throw new Error("initSaml requires GRIST_SAML_IDP_LOGIN to be set"); }
          if (!process.env.GRIST_SAML_IDP_LOGOUT) { throw new Error("initSaml requires GRIST_SAML_IDP_LOGOUT to be set"); }
          if (!process.env.GRIST_SAML_IDP_CERTS) { throw new Error("initSaml requires GRIST_SAML_IDP_CERTS to be set"); }
          
          const spHost: string = process.env.GRIST_SAML_SP_HOST;
          const spOptions: saml2.ServiceProviderOptions = {
            entity_id: `${spHost}/saml/metadata.xml`,
            private_key: await fse.readFile(process.env.GRIST_SAML_SP_KEY, {encoding: 'utf8'}),
            certificate: await fse.readFile(process.env.GRIST_SAML_SP_CERT, {encoding: 'utf8'}),
            assert_endpoint: `${spHost}/saml/assert`,
            notbefore_skew: 5,      // allow 5 seconds of time skew
            sign_get_request: true  // Auth0 requires this. If it is a problem for others, could make optional.
          };
          this._serviceProvider = new saml2.ServiceProvider(spOptions);
          
          const idpCerts = process.env.GRIST_SAML_IDP_CERTS.split(",");
          const idpOptions: saml2.IdentityProviderOptions = {
            sso_login_url: process.env.GRIST_SAML_IDP_LOGIN,
            sso_logout_url: process.env.GRIST_SAML_IDP_LOGOUT,
            certificates: await Promise.all(idpCerts.map((p) => fse.readFile(p, {encoding: 'utf8'}))),
            // Encrypted assertions are recommended, but not necessary when over https.

If you are comfortable recompiling Grist, you could try increasing this number (and we should make it configurable).

Alternatively, you could be right that there is a timezone issue involved. I see a warning about this in Authentik’s documentation at Docker Compose installation | authentik

Dan6erbond · January 19, 2023, 9:30am

Responding here to keep the thread active - I did some further debugging and tried setting the timezone to UTC, not setting at all, and checked out the Grist and Authentik logs. I wasn’t able to get any different outcomes from changing those parameters.

I can try to recompile Grist with a higher skew. But since I ran date in both containers and got the exact same output, I feel like the issue lies somewhere else.

Dan6erbond · January 19, 2023, 10:33am

I found the issue: I was using Terraform to create the Authentik SAML provider for Grist, which was setting different default values than the UI does.

One of those was the “Assertion not valid before” to minutes=3 which needs to be a negative number like minutes=-3. My Terraform config looks like this now:

resource "authentik_provider_saml" "grist_saml_provider" {
  name               = "grist-saml-provider"
  acs_url            = "https://${var.host}/saml/assert"
  authorization_flow = data.authentik_flow.default_authorization_flow.id
  sp_binding         = "post"
  signing_kp         = data.authentik_certificate_key_pair.self_signed.id
  verification_kp    = data.authentik_certificate_key_pair.grist.id
  property_mappings = concat(
    data.authentik_property_mapping_saml.managed.ids,
    [
      data.authentik_property_mapping_saml.first_name.id,
      data.authentik_property_mapping_saml.last_name.id,
    ]
  )
  name_id_mapping               = data.authentik_property_mapping_saml.uid.id
  assertion_valid_not_before    = "minutes=-3"
  session_valid_not_on_or_after = "minutes=86400"
}

After doing that, Grist was able to create my account, and give me access to the workspace. Important was just that I set GRIST_DEFAULT_EMAIL to the first mail account that logs in.