I try to setup JWT validation, I validate token from Azure AD
My concern is to load the signin key for verify inside kong, I use the kubectl way, I have see
on the documentation than all fields are required as the secret “field”.
From the doc: You should always fill out key , algorithm , and secret . If you use the RS256 or ES256 algorithm, use a dummy value for secret .
So I use this command :
kubectl create secret generic poc-msf-aad -n kong
–from-literal=kongCredType=jwt
–from-literal=rsa_public_key="-----BEGIN PUBLIC KEY-----
aaaaaaaabbbbbbb
-----END PUBLIC KEY-----"
–from-literal=algorithm=RS256
–from-literal=key=“https://login.microsoftonline.com/67357eed-9531-498d-9f78-d895d88ed1e1/v2.0”
–from-literal=secret=dummy
I tried many was to ingest this secret but I have always this error :
failed conditional validation given value of field ‘algorithm’"]}]}]},“name”:“invalid declarative configuration”,“code”:14,“message”:“declarative config is invalid: {consumers={{jwt_secrets={{[\”@entity\"]={\“failed conditional validation given value of field ‘algorithm’\”},rsa_public_key=\“invalid key\”}}}}}"}" component=sync-queue
$ helm list -n kong
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
kong-ingress kong 1 2020-10-19 14:43:06.3501612 +0200 CEST deployed kong-1.11.0 2.1
You’ll likely have considerable difficulty doing this with the JWT plugin in practice: from my past experience with Azure AD, it’s designed with the expectation that the application performing validation is performing a number of tasks as part of a rich authentication system, most commonly OpenID Connect (they offer non-OIDC OAuth2 as well, but OIDC is essentially a richer set of standards that seeks to address some of the shortcomings in the original OAuth2 spec).
The JWT plugin is designed for simpler systems that sign JWTs using a static RSA key or HMAC secret. Although JWTs are a component in Azure AD’s OIDC implementation, it expects the application using it for authentication to perform a number of other tasks beyond JWT validation to implement authentication effectively and securely.
The error you’re seeing is because that field expects a PEM-encoded RSA public key, not a URL. Azure AD uses various URLs to provide OIDC discovery information, including a JSON Web Key set URL. While that URL does provide RSA keys, they’re not in PEM form, and they furthermore rotate periodically. OIDC plugins include tooling to parse the contents of those JWKS URLs and update their local key information automatically, but the JWT plugin does not.
Nokia maintains an open source OpenID Connect Kong plugin, and it should be possible to configure it with Azure AD, but I don’t have any detailed information on that.
Regarding you remark, the rsa key is associated to pem key in my command (begin public key…), I took the key from the jws keys, it’s not an url.
the key field is associated to an url
I tried the same command with another provider based on openam with the same result
If you have any advice
I tried nokia oidc plugin, it seems to work fine for the oidc flow “authorization code” (interactive)
but I need to implement the oidc flow “client credentials” (M2M authentication), the only example I find
is belon and use the jwt plugin
Ah–I saw the URL there and figured it was in the RSA key field. My mistake.
If it’s still complaining about that with the actual PEM key, my best guess is that there’s either some issue in the original conversion from the JWK format or an issue when creating the Secret.
Creating a Secret containing multiline fields via the CLI tool may be more trouble than it’s worth. Although it’s likely possible, I’d recommend writing your Secret out in a YAML file instead and uploading it using kubectl create -f /path/to/secret.yaml. You can use stringData to provide values in plaintext (e.g. as shown in the K8S documentation) and then use a multiline string to keep the PEM newlines intact.