We held a meeting yesterday and have come to the following:
- We are introducing the concept of an "Override Token" (term might change), which would be a secondary token that would be sent along with the standard access token in a different header for the request. This token would be an opaque, signed token that would carry in its payload a list of extra permissions that would be granted to the user. It would carry an expiration time, so as to become invalid after a short period.
- When mod-authtoken receives this Override Token, it will decrypt it and add the contained permissions to the user's permissions for the current request. It will also add these permissions to the tokens generated for any modules along the current request chain, so that the modules will be able to take advantage of the override for the request.
- The process of minting a new Override Token will be done via a new endpoint on mod-login, perhaps /authn/override. The supervisor user will provide, to the endpoint, their credentials, along with the userid being granted the token, a list of the supervisor's permissions that will be granted by the token, and the time-to-live of the token. The response from the endpoint will be the override token. The advantage to this scheme is that the supervisor never exposes their access token to the user's browser, which helps close a potential security hole.
- The following components would need to be changed to make this work:
- mod-authtoken: Would need to be able to recognize and decrypt the new tokens, and to incorporate the contents into the request chain.
- mod-login: Would need new endpoint to permit minting of the Override Token
- okapi: Would need to recognize the new header (X-Okapi-Override?) and pass along accordingly
- stripes: Would need changes to be able to provide login for supervisor to create override token, and would need to be able to attach the new token to the overridden request in the new header.