[BUG] JWT Authentication Backend Fails to parse public keys in security-config.yml #4406
Comments
trevorlyman
added
bug
|
[Triage] Hi @trevorlyman, thank you for filing this issue. Quickly looking at your configuration, the issue you're experiencing is likely caused by the format of your public key. You have Which has a leading That being said, you are welcome to open a PR to improve the key parsing functionality for the JWT auth backend. |
stephen-crawford
added
triaged
|
Thanks for looking at this bug. With and without the This config: ...
jwt_auth_domain:
description: "Authenticate via Json Web Token"
http_enabled: true
transport_enabled: true
order: 0
http_authenticator:
type: jwt
challenge: false
config:
signing_key: |
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA64L6PDUm1ySNWIJiuxEv
OA92MDmrevshZEWQsN98pkrp8pbCOVjA5OseddXOYVlXunbv1FMooGwVkOCAk6s3
rxffHP2tN4NJRvvEDr/uoWKj22mV9cqyVar13HvdKkTm0MN1nDjo1fv1YBL5Xq7E
2Ak6d0soKIg/RFzzv7JqLkUCsQ5krhm08A11cBbI8jqsebsiRCa7HkRyUalYLRVh
NHf9Dxf3rmVoKtHs1jKRMm9NiAl1aa6U/BDzlM45uX9yNaOYiqNVbQIufwxiy4/a
gbmkvuqTf/Pm6jzX09h0nb7CIiy+3AbbnncaZ8UjwKZ8iJJ8XTDtHuerM8eN728F
NwIDAQAB
-----END PUBLIC KEY-----
jwt_header: "Authorization"
...Produces this error message: If it's expected that users should use |
|
Hi @trevorlyman, You can use this: Feel free to open a PR changing the public key parsing logic and/or the documentation. |
|
are you sure this is something that needs to be fixed in documentation, rather than in codebase? |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the bug?
The
jwt_auth_domainauthentication backend fails to parse thesigning_keyvalue when the key is formatted in as a PEM as shown in the documentation. The key can be read if the PEM headers are stripped out and the base64 content of the key is provided as a single line.How can one reproduce the bug?
Steps to reproduce the behavior:
jwt_auth_domainauthentication backend with the following key:... jwt_auth_domain: description: "Authenticate via Json Web Token" http_enabled: true transport_enabled: true order: 0 http_authenticator: type: jwt challenge: false config: signing_key: |- -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA64L6PDUm1ySNWIJiuxEv OA92MDmrevshZEWQsN98pkrp8pbCOVjA5OseddXOYVlXunbv1FMooGwVkOCAk6s3 rxffHP2tN4NJRvvEDr/uoWKj22mV9cqyVar13HvdKkTm0MN1nDjo1fv1YBL5Xq7E 2Ak6d0soKIg/RFzzv7JqLkUCsQ5krhm08A11cBbI8jqsebsiRCa7HkRyUalYLRVh NHf9Dxf3rmVoKtHs1jKRMm9NiAl1aa6U/BDzlM45uX9yNaOYiqNVbQIufwxiy4/a gbmkvuqTf/Pm6jzX09h0nb7CIiy+3AbbnncaZ8UjwKZ8iJJ8XTDtHuerM8eN728F NwIDAQAB -----END PUBLIC KEY----- jwt_header: "Authorization" ...OpenSearch-key-load.log
What is the expected behavior?
The key should be loaded correctly
What is your host/environment?
{ "name": "opensearch-node1", "cluster_name": "opensearch-cluster", "cluster_uuid": "uC4_Zj7vS5Cv2n87CIcQzA", "version": { "distribution": "opensearch", "number": "2.14.0", "build_type": "tar", "build_hash": "aaa555453f4713d652b52436874e11ba258d8f03", "build_date": "2024-05-09T18:51:00.973564994Z", "build_snapshot": false, "lucene_version": "9.10.0", "minimum_wire_compatibility_version": "7.10.0", "minimum_index_compatibility_version": "7.0.0" }, "tagline": "The OpenSearch Project: https://opensearch.org/" }opensearchproject/opensearch:sha256:756d2401537847f8bfb158a02a649a46adf7e7d15303a3692ed3d76586189d12Do you have any additional context?
This is a valid key. The code for parsing the public keys seems a bit buggy. The key loads correctly if it is formatted as a single line string without the PEM headers.
Code in question
The parsing of the public key looks to happen here.
Additional Concerns
I'm also concerned that because of the way the parsing code works that a public key may get misinterpreted as a HMAC key if parsing of the public key fails. By immediately clearing the PEM headers when parsing important context from the user is lost. Consider
a situation where a public key was slightly malformed and could not be parsed as RSA or ECC and got interpreted as an HMAC string.
The text was updated successfully, but these errors were encountered: