Comply with university minsec standards

[mjgiarlo]

This issue will be fleshed out in an upcoming meeting.

Stanford MinSec standards

sdr-api should, e.g.:

• Enable host-based firewall in default deny mode and permit the minimum necessary services.
  • Compare with what's in puppet?
• Review existing accounts and privileges quarterly.
  • Needs discussion
• Enforce password complexity
  • Currently require a length of at least six characters (up to 72 bytes), so this is ripe for improving.
  • That said, the credentials we've created for system accounts have used strong passwords
• Logins with SUNet credentials via WebAuth/SAML recommended.
  • This could be an opportunity for improvement worth discussing: sdr-api could have local credentials for system accounts (e.g., for GBooks/H2 integration) combined with SSO authentication for regular users?
• Require Duo two-step authentication for all user and administrator logins.
  • See prior bullet

Token Usage

• Given a set of credentials matching what's in the app database, the app will issue a token:
  • It's a JSONWebToken
  • It is encrypted using the application's secret key
  • The payload includes the user's ID (allowing the app to map a token back to its user)
  • The token is good for 24h (and we have complete control over this expiry time)

[mjgiarlo]

Current Design

sdr-api

• All requests are via the HTTPS protocol.
• All requests to the API, except authentication login requests, are authorized (via this method) if and only if:
  • the request has an Authorization header containing a JSON Web Token (or JWT); and
  • the JWT can be decoded with the app's secret key (because it was encoded by the app's secret key);
  • the JWT has an expiration date that has not yet passed; and
  • the JWT contains a user ID that corresponds to a user ID in sdr-api's database (so that actions taken in sdr-api can be tied to a particular user)
• Authentication login requests, on the other hand, contain an email and a password parameter and these requests succeed only if sdr-api has a user with the specified email and password
  • On successful login, a valid JWT is returned, expiring in 24 hours
  • On a failed login, sdr-api returns an HTTP 401 error response
• The authentication controller also has a proxy endpoint, used by Argo (see below), that first (as mentioned above) authorizes the JWT if and only if the JWT contains a user ID that corresponds to a user ID in sdr-api's database; and the user with that ID has an email that matches the Argo service account email in the sdr-api application configuration
  • If the above conditions are false, the API returns an HTTP 401 error response
  • If they are true, the request's to parameter specifies the user's ID and that ID is either found in the database or it is created with an opaque, secure (e.g., complex & reasonably long) password that is never viewed, changed, or used and is persisted in the application database as a bcrypt-encrypted digest
• JWTs that are emitted are not persisted anywhere in the application, and thus cannot be revoked; as currently configured, all JWTs expire after 24 hours
  • The best we can do, currently, is mark a user instance in the application database as an "inactive" user, which causes the API to return HTTP 401 errors for any resource-related requests (creates, updates, reads).
• User accounts (with email addresses and passwords) are persisted to the application database
  • There are currently two flavors of accounts: service accounts and user accounts. The former have fake email addresses and the latter have SUNet email addresses. The former are used by apps like H2 and GBooks to create and update resources, and one is also used by Argo (see below) to obtain tokens on behalf of users.
  • Passwords for user accounts are typically set to a random value (via the proxy endpoint described above) not known by anyone, and thus effectively can't be used for login

sdr-client

• sdr-client is used as a CLI for SDR, and it interacts with the APIs provided by sdr-api
• sdr-client has a login action that prompts the user for an email and a password and hits sdr-api's login endpoint (see above), and then caches the JWT in a hidden file, and then reads from the cache for subsequent operations

argo

• argo exposes a tokens endpoint that allows all argo users to uses the sdr-api proxy endpoint (see above) to generate a valid JWT for Argo users to be able to interact with sdr-api (it's only used as part of the team's integration tests in the QA and staging environments)
  • clearly a key assumption here is that sdr-api trusts argo's own SAML-based authentication and workgroup-based authorization to make sure tokens are not issued for users that should not have access to sdr-api

[mjgiarlo]

Proposed Design

TBD

[mjgiarlo]

We will revisit this ticket after we meet with API partners and learn their functional & technical requirements.