Creating (internal) Users and authenticating them using JWT


I configured JWT authentication with “authentication_backend” intern:
config.yml (snippet) looks like this:

        description: "Authenticate via Json Web Token"
        http_enabled: true
        transport_enabled: true
        order: 0
          type: jwt
          challenge: false
            signing_key: |-
              -----BEGIN PUBLIC KEY----- 
              -----END PUBLIC KEY-----
            jwt_header: "Authorization"
            jwt_url_parameter: null
            roles_key: null
            subject_key: null
           type: intern

Authentication via a JSON Web Token works fine due to the configuration above.
In addition to auth via JWT, i also configured basic auth for user in the internal database.

        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
          type: basic
          challenge: true
          type: intern

My question is: Is it possible to authenticate internal user (created by user api) by using JWT?
In order to do this, i tried to configure “intern” as authentication_backend (see last part of jwt config snippet). This works as long as the code try to authenticate the user passed by jwt against internal user database using basic auth. Due to the fact that the JSON Web Tokens doesn’t contain a /the password within its payload, the authentication fails.

Any ideas for a workaround or any similar?

One hacky thing, i tried out, works like this: I build a “patch” of the opensearch-security plugin, where the InternalAuthenticationBackend doesn’t check the password, so the user (from json web token) can be authenticated against the internal user database and infos like roles and attributes can be fetched from the database.

Thanks for hints, ideas or feedback.

I will try to present my idea or my intention more precisely:

  • System: Search Engine using OpenSearch
  • Each search request contains a json web token
  • Json web tokens are generated after authentication (e.g with ldap) by using a public/private key pair. Public key is configured in config.yml of opensearch security.
  • These json web tokens do not contain any information about user groups. Since the amount of groups in the system can become very large, i don’t want to store group infos within the token.
  • So after a search request is received by OpenSearch, the user is already authenticated, but the search engine does not have any informations about the (search) user’s groups which are
    necessary for Document level security.
  • In order to get search user’s groups (for building query filters),
    there will be an external separate service that provides user informations (groups) on demand. (This service is requesting directly the source systems, e.g ldap, …)
  • In order to avoid requesting the external service with each search request, user informations (groups) have to be cached!
    The idea is to use the existing database for internal users for this purpose.

What do you think about this approach?

  • In oder to achieve this i configured JWT authentication with “authentication_backend” = intern in config.yml. (see my first post in this topic).
    As i already mentioned, this works fine as long as the code try to authenticate the user passed by jwt against internal user database using basic auth.
    Since jwt does not contain a password, the authentication fails.
    So after having a deeper look in opensearch-security code, i see a possibility to implement my own custom “AuthenticationBackend”.

Any feedback or feelings concerning this way?

If I am implementing own features in opensearch-security, what would be the best (official) way to publish it?

  • Creating a pull request for opensearch-security?
  • Plugin of the opensearch-seucrity- plugin? Is this possible?
  • Any other?

Thanks for any kind of feedback, possible solutions and hints!

Hello @Oers - welcome to the OpenSearch community. Really interesting use case - I’ll pass this around with some of the developers to see if they have input.

1 Like

Hi @kris,

That would be very helpful and would make me very happy!