feat: Add sdf whoami endpoint accessible to user or automation tokens

[jkeiser]

This adds a "whoami" endpoint that you can hit to check your token and email (who SI thinks you are). It mainly exists to validate that we can actually authorize automation tokens for an endpoint (since all other endpoints reject automation tokens).

Extractor Funnel

This also factors the token and authorization extractors so they always use the same code. web/automation authorization still work via extractors, they just all run through a single funnel now.

EndpointAuthorization is the main authorization extractor you will use (or AccessBuilder, which uses it), which:

1. Extracts the access token from the Authorization: header using the RawAccessToken extractor.
2. Validates the access token and checks expiration date using the ValidatedToken extractor.
3. Checks that the user is a member of the workspace using the WorkspaceMember extractor.
4. Checks that the token gives the user "web" permissions using the AuthorizedRole extractor.
5. Returns the workspace_id, user record, and the role that was authorized.

Customization For Different Endpoints

The big reason to break this up was to allow different authorization for different endpoints, as well as to support WS endpoints using the same extractors. The AuthorizedRole and RawAccessToken extractors check if they already have a value before doing their default behavior, so you can invoke other extractors that set the value first. To wit:

• The whoami endpoint doesn't need maximal permissions (the web role), so it adds the _: AuthorizeForAutomationRole extractor to its endpoint function, causing endpoint validation to check for the automation role instead.
• WS endpoints add the _: TokenFromQueryParam extractor to the endpoint function, which retrieves the token from the "token" query parameter instead of the Authorization header.

Where appropriate, these endpoints cache their results so that if you use multiple extractors (which we do frequently) you don't pay a double or triple database access or public key decryption penalty.

This also adds Deref and Into to a lot of the extractors, which means instead of saying things like Nats(nats): Nats you can just say nats: Nats and still use the nats object like normal.

Future

Going forward, we'll want to take some of this (RawAccessToken and ValidatedToken in particular) and move it to a common library (quite possibly repurpose si-jwt-public-key for it) so that the module index can use them. I started to do that, but there's a minor snarl in that it needs to be able to access the public key we grab as part of AppState (which isn't shared between module index and sdf). Will get back to that at a later time.

[github-actions]

Dependency Review

✅ No vulnerabilities or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Files

[zacharyhamm]

A few ?s

[zacharyhamm]

Tested this by replacing my local workspace token with one for another user (my gmail account) but for the same "workspace id" (without modifying the token, just the key on the data bag in the local storage). This seems good to me, although for something this sensitive another set of eyes might be worthwhile

[jkeiser]

I think I will wait to merge our auth stack until it's NOT 5PM on Friday. :)