The token cannot be accepted yet

Hi pals,

I am installed the SG on my elastic stack. Here are my config:

# kibana.yml:

elasticsearch.username: "kibanaserver"
elasticsearch.password: "kibanaserver"
elasticsearch.ssl.verificationMode: none
elasticsearch.requestHeadersWhitelist: [ "Authorization", "sgtenant" ]
searchguard.auth.type: "openid"
searchguard.openid.connect_url: "<my identity server>/.well-known/openid-configuration"
searchguard.openid.client_id: "my_clientid"
searchguard.openid.client_secret: "my_secret"
searchguard.openid.scope: "profile openid roles"
searchguard.openid.header: "Authorization"
xpack.security.enabled: false
server.host: "<kibana host>"
elasticsearch.preserveHost: false
elasticsearch.url: "<elastic search url>:9200"
# elasticsearch.yml:

bootstrap.memory_lock: false
cluster.name: elasticsearch
http.port: 9200
node.data: true
node.ingest: true
node.master: true
node.max_local_storage_nodes: 1
node.name: <Node name>
path.data: <directory>\data
path.logs: <directory>\logs
transport.tcp.port: 9300
xpack.license.self_generated.type: basic
xpack.security.enabled: false

searchguard.ssl.transport.pemcert_filepath: esnode.pem
searchguard.ssl.transport.pemkey_filepath: esnode-key.pem
searchguard.ssl.transport.pemtrustedcas_filepath: root-ca.pem
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.pemcert_filepath: esnode.pem
searchguard.ssl.http.pemkey_filepath: esnode-key.pem
searchguard.ssl.http.pemtrustedcas_filepath: root-ca.pem
searchguard.allow_unsafe_democertificates: true
searchguard.allow_default_init_sgindex: true
searchguard.authcz.admin_dn:
  - CN=kirk,OU=client,O=client,L=test,C=de
searchguard.enable_snapshot_restore_privilege: true
searchguard.check_snapshot_restore_write_privileges: true
searchguard.restapi.roles_enabled: ["sg_all_access"]

network.host: 0.0.0.0
http.cors.allow-origin: "*"
http.cors.enabled: true
# sg_config.yml

searchguard:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
        remoteIpHeader:  'x-forwarded-for'
        proxiesHeader:   'x-forwarded-by'
    authc:
      basic_internal_auth_domain:
        enabled: true
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: internal
      openid_auth_domain:
        enabled: true
        order: 1
        http_authenticator:
          type: openid
          challenge: false
          config:
            subject_key: preferred_username
            roles_key: role
            openid_connect_url: <my identity server>/.well-known/openid-configuration
        authentication_backend:
          type: noop

I have also added the hr and kibanauser roles in the Identity Server configurations and have the following configurations in the search guard, as well:

# sg_roles.yml:

sg_human_resources:
  cluster:
    - CLUSTER_COMPOSITE_OPS
  indices:
    '*':
      '*':
        - UNLIMITED
# sg_roles_mapping.yml:

sg_human_resources:
  backendroles:
    - hr

Running the command
.\sgadmin.bat -cd ..\sgconfig -key ..\..\..\..\config\kirk-key.pem -cert ..\..\..\..\config\kirk.pem -cacert ..\..\..\..\config\root-ca.pem -nhnv -icl
it gets done with success. But when I login to the Identity Server (to be redirected to the Kibana), the Search Guard does not redirect me to the Kibana, and it shows the message that authentication has encountered a problem. Looking at the logs, I receive the following message:

[c.f.d.a.h.j.AbstractHTTPJwtAuthenticator] [<Server name>] Extracting JWT token from "<Token>" failed
com.floragunn.dlic.auth.http.jwt.keybyoidc.BadCredentialsException: The token cannot be accepted yet
at com.floragunn.dlic.auth.http.jwt.keybyoidc.JwtVerifier.getVerifiedJwtToken(JwtVerifier.java:59) ~[dlic-search-guard-enterprise-modules-6.5.4-33.1.jar:6.5.4-33.1]
	at com.floragunn.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator.extractCredentials0(AbstractHTTPJwtAuthenticator.java:102) [dlic-search-guard-enterprise-modules-6.5.4-33.1.jar:6.5.4-33.1]
	at com.floragunn.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator.access$000(AbstractHTTPJwtAuthenticator.java:44) [dlic-search-guard-enterprise-modules-6.5.4-33.1.jar:6.5.4-33.1]
	at com.floragunn.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator$1.run(AbstractHTTPJwtAuthenticator.java:84) [dlic-search-guard-enterprise-modules-6.5.4-33.1.jar:6.5.4-33.1]
	at com.floragunn.dlic.auth.http.jwt.AbstractHTTPJwtAuthenticator$1.run(AbstractHTTPJwtAuthenticator.java:81) [dlic-search-guard-enterprise-modules-6.5.4-33.1.jar:6.5.4-33.1]
	at java.security.AccessController.doPrivileged(Native Method) [?:1.8.0_202]
.
.
.

When I reset the Elastic Search service and reconfigure the Search Guard for several times, the issue gets solved.

What should I do to resolve the issue completely?

Best,
Behzad

Hi,

the usual request flow is to access Kibana first, then you get redirected to the IdP, and after successful login you will get redirected to Kibana again with the JWT token from the IdP. Can you please try this flow?

Also, this error message:

com.floragunn.dlic.auth.http.jwt.keybyoidc.BadCredentialsException: The token cannot be accepted yet

indicates that the JWT the IdP issues is not valid yet. JWTs may contain a “not-before” claim. If this date is in the future you will see the exception above.

https://tools.ietf.org/html/rfc7519#section-4.1.5

Can you please check if your IdP is configured correctly? You can check the JWT with this tool for example:

Thanks for your reply.

I just follow the flow you mentioned in your message. The login is successful from the IdP and I am redirected to the Kibana page, but receive an error message from the SG saying that the authentication failed. Checking the logs, I receive the error mentioned in my message.

The date of the server is correct, I just checked.

As mentioned earlier, when re-configuring the SG for several times, the error gets solved. It is really surprising for me!

I also checked the token in the link you mentioned. It is configured correctly.

Is it possible to post the actual JWT here? If it contains sensitive information you can also send it via a PM.