Feat/jwt fallback

[vpsx]

What:
This PR changes the GET /auth/mapping endpoint so that if no username is supplied in the query args, Arborist will fall back to the JWT and get the username from there if present.

This related revproxy PR uc-cdis/cloud-automation#1006 exposes GET /auth/mapping (and only GET--not POST) but does not pass the username qp to Arborist.

This related windmill PR uc-cdis/data-portal#592 hits the endpoint via the proxy.

Why:
We expose GET /auth/mapping so that Windmill can hit it and get the logged-in user’s authz info, but we do not pass the username arg (and do not expose POST) to prevent users checking other users’ access. We do not just check the jwt in Arborist because other services need to hit this without a jwt.

So now Windmill will be able to hit GET /auth/mapping with the user’s jwt, /auth/mapping will remain secure against users checking other users’ access, and other gen3 services will still be able to hit /auth/mapping without a jwt.

This does lead to the following funny behavior if a logged-in user A tries to see another user B’s auth mapping: 1. user A hits commons-url/authz/mapping?username=user-B@email.com; 2. revproxy strips the username arg and hits Arborist’s GET /auth/mapping endpoint; 3. Arborist sees no username qp, checks the jwt, gets user A’s username, and returns user A’s auth mapping; 4. user A probably thinks that they successfully got user B’s mapping and that it happens to be identical to their own.

tldr

• Logged-out user hits commons-url/authz/mapping with or without username arg—gets 400 user does not exist
• Logged-in user hits commons-url/authz/mapping with or without username arg—gets own access mapping
• Anything hits commons-url/authz/mapping with method other than GET—gets 403 forbidden by nginx

New Features

• In GET /auth/mapping, fall back to jwt if no username in query args

[coveralls]

Coverage decreased (-0.2%) to 73.487% when pulling eda2f12 on feat/jwt-fallback into 9067a3e on master.