Update secure web service group membership checks

Currently members of a parent group are included. Should only include groups where user is a direct member.

• for users, use "groups_direct" list of groups returned by gitlab openid
• for tokens, update automated process to create session by sending token to /login endpoint.
  • backend should check direct group membership for roles/observer, roles/reviewer, and roles/admin using token and populate list of groups in session

authenticated requests to create/update metadata will then always include a session id, and only use the token during authentication.

Gitlab returns groups_direct with the token after oauth2 authentication, which has the desired info: https://docs.gitlab.com/ee/integration/openid_connect_provider.html

This wouldn't work the same for token based auth that uses the gitlab api instead of oauth2. Still researching, may need to update automated clients authentication.

Issue description updated with plan.

changed the description

@erigler : here's a rough outline of what I'm thinking. I think the metadata factory would have minor updates to manage the session cookie but would otherwise work similarly...

Group tokens can be created in gitlab for automated processes. These show the "user" is a direct member of the group using requests like:

curl -H 'PRIVATE-TOKEN: _token_goes_here' https://code.usgs.gov/api/v4/user
curl -H 'PRIVATE-TOKEN: _token_goes_here' https://code.usgs.gov/api/v4/groups
curl -H 'PRIVATE-TOKEN: _token_goes_here' https://code.usgs.gov/api/v4/groups/ghsc%2Fgeomag%2Foperations%2Froles%2Freviewer/members

API would be updated to:

• accept token only on login endpoint
• when api token (with read_api permission) received, check direct group membership in groups
  • roles/reviewer (reviewer permissions)
  • roles/observer (create only) groups
• store user object in session that is used during later requests

Automated processes would be updated to:

• send login request with token, use requests.session in python to store session cookie
• send other requests to api as needed for session
• optionally, store session info across multiple command line execs

For normal users, use groups_direct from response for direct membership checks.

Probably a super basic question, but how does this differ from the current setup?

In the current setup, the list of all groups (inherited or direct membership) is used. Both for regular users (via oauth) or gitlab api tokens (via gitlab api).

We would use the more specific groups_direct list for users authenticating using oauth, and check for direct membership in a short list of groups via the gitlab api for scripts using gitlab api tokens.

This sounds good to me. For now I'm assuming you will make the needed changes (I see a test token for the observer group already). If not, let me know ASAP so I can start looking closely at the API code, and asking more specific questions.

@erigler better if you can implement these changes, happy to advise