Ticket 9993

(In reply to Nate Rini from bug#9990 comment #3)
> > 2 - Regarding JWT based authentication. Will slurmrestd be able to verify
> > the JWT signed by DKube? Or do we need a proxy infront of it which can use
> > DKube as a JWKS verifier?
> I'm unfamiliar with DKube but it should work as long as the correct fields
> are present and it is signed with the same key.
> 
> Fields:
> > sun -> username
> > exp -> unix timestamp of expiration date

Created attachment 16221 [details]
patch for 20.02

Created attachment 16909 [details]
patch for 20.11

(In reply to Ben Roberts from comment #5)
> I took a look at the patch you have thus far and have a few comments.  
> 1.  I'm not a fan of the "In theory" at the beginning of the second
> sentence.  I would say we should only document this if we know it works with
> tokens that meet these requirements.  If we know it does then we can take
> the "In theory" out.
We need to test this but I believe one site has already done it. If it doesn't work, I would consider it a bug on Slurm's part assuming they meet the requirements listed.

> 2.  I don't care for the "Slurm's tokens" h3 heading where it is.  Above it
> says "...as long as the following tokens are granted:" and then it should go
> right into the list.  The extra heading in between the semicolon and the
> list make it confusing.
Removed.

> 3.  Do these tokens have to be in a certain order?
Nope, the token is actually made using JSON.

> If not I think it would
> make more sense to put the creation timestamp first, expiration timestamp
> and then the username.  This is obviously just a matter of preference and
> not a huge deal.  If the order doesn't matter then it might also be worth
> changing it to an unordered list.
done. I have no preference w/r to order.

> 4.  I would expound a little on the "Slurm UserName" (I would prefer to have
> it written in camel-case to explain the acronym rather than brackets). I
> believe this is the Slurm User for slurmctld, right?  I would specify that. 
> I don't see the benefit of linking to the posix definition of user names
> (thought I could be missing it).

I did that so I didn't have to explain what a user name was to our more web-based sites that are not used to POSIX/Unix.  My main concern is that they may confuse the field for an OAuth2 user name which is the usual value for a user name which may not be the same as our user names. Pls feel free to drop it if you consider it redundant but I choose to be specific for our docs rather than not.

Thanks Nate, this has been checked in.

commit c4753c38265c2fbdaaf5391ad3ad87c36339e82d
Author: Nate Rini <nate@schedmd.com>
Date:   Wed Oct 14 15:28:38 2020 -0600

    Docs - auth/jwt - Document JWT compatibility
    
    Bug 9993