We are looking into integrating SLURM Rest with our SSO (AzureAD) to create external JWT tokens to be validated with JWKS keys. We have been successful, however we run into a couple of issues and so we want to document this and maybe suggest some enhancements. We are using AzureAD application with OpenID Connect SSO integration. We managed to create a JWT with the required fields (sun, iat and exp). 1.) However out of the box Slurm can't validate the JWT because the code in https://github.com/SchedMD/slurm/blob/slurm-22-05-8-1/src/plugins/auth/jwt/auth_jwt.c#L293 looks for a JWKS key with the corresponding kid and the alg set to "RS256". The jwks.json file that you receive from the AzureAD OIDC application endpoint(see as an example: https://login.microsoftonline.com/35e19b4a-02bb-4975-aaba-acc04ac3ebaf/discovery/v2.0/keys) does not contain this field. Accoridng to the spec (see: https://www.rfc-editor.org/rfc/rfc7517#section-4.4) this field is optional. So if we use the jwks.json file provided by the OIDC endpoint, the SLURM Rest call will fail with "error: could not find matching kid or decode failed" As a workaround we manually added "alg":"RS256" to the keys in the jwks.json file and the SLURM Rest call was successful. Is the check for alg == RS256 really necessary if it is anyway matched by the "kid" which should be unique ? 2.) Currently one has to download the JWKS keys manually and put them to a location where slurmdbd and slurmctld can access them. However it would be an enhancement if Slurm would accept an URL instead for either the "OpenID Connect metadata document" (see: https://login.microsoftonline.com/35e19b4a-02bb-4975-aaba-acc04ac3ebaf/v2.0/.well-known/openid-configuration) which contains the URL to the jwks keyfile or the URL to the jwks keyfile itself. Additionally these JWKS keys are/can be roatated. It would be a nice enhancement if Slurm would check if it can match the kid and if not maybe retrieve the rotated JWKS keys from the above mentioned well known URLs. 3.) If the above is not possible. It would be nice if the JWKS keys would be re-loaded from disk via a systemctld reload slurmctld/slurmdbd instead of a restart. Thanks Ümit
We are reviewing your request and should respond soon.
(In reply to timeu from comment #0) > 1.) However out of the box Slurm can't validate the JWT because the code > in > https://github.com/SchedMD/slurm/blob/slurm-22-05-8-1/src/plugins/auth/jwt/ > auth_jwt.c#L293 looks for a JWKS key with the corresponding kid and the alg > set to "RS256". The jwks.json file that you receive from the AzureAD OIDC > application endpoint(see as an example: > https://login.microsoftonline.com/35e19b4a-02bb-4975-aaba-acc04ac3ebaf/ > discovery/v2.0/keys) does not contain this field. Accoridng to the spec > (see: https://www.rfc-editor.org/rfc/rfc7517#section-4.4) this field is > optional. So if we use the jwks.json file provided by the OIDC endpoint, the > SLURM Rest call will fail with "error: could not find matching kid or decode > failed" > As a workaround we manually added "alg":"RS256" to the keys in the jwks.json > file and the SLURM Rest call was successful. > > Is the check for alg == RS256 really necessary if it is anyway matched by > the "kid" which should be unique ? Looking into how best to handle "alg" not being set. > 2.) Currently one has to download the JWKS keys manually and put them to a > location where slurmdbd and slurmctld can access them. However it would be > an enhancement if Slurm would accept an URL instead for either the "OpenID > Connect metadata document" (see: > https://login.microsoftonline.com/35e19b4a-02bb-4975-aaba-acc04ac3ebaf/v2.0/. > well-known/openid-configuration) which contains the URL to the jwks keyfile > or the URL to the jwks keyfile itself. > Additionally these JWKS keys are/can be roatated. It would be a nice > enhancement if Slurm would check if it can match the kid and if not maybe > retrieve the rotated JWKS keys from the above mentioned well known URLs. There are currently no plans to implement automated retrieval of the JWKS keys. > 3.) If the above is not possible. It would be nice if the JWKS keys would be > re-loaded from disk via a systemctld reload slurmctld/slurmdbd instead of a > restart. This is an area of possible changes for the next major release.
(In reply to Nate Rini from comment #4) > Looking into how best to handle "alg" not being set. We are preparing a corrective patch to honor "alg" being optional.
We have modified auth/jwt to ignore the 'alg' field not existing for the upcoming Slurm-23.02.6 release: > https://github.com/SchedMD/slurm/commit/19f42376749a0dd8c9fd6cbdfbc15c57fcd70c3b This should resolve the issue with the Azure AD JWKS file. Please reply if there are any more questions or related issues.
