Login

client calls login for the creds it has and gets an auth token. The auth token is then sent on each method call

db schema for security:

users

------

username | password | salt | token (default null) | token_expiration_ts (default 0)

Important Notes

• No allowance for granular permissioning. All users will have access to all data.
  • We intend to support the use cases where an application uses a single set of creds. There may be a few other creds for admins to occasionally access Concourse via the command line. Either way, there is really no need to support granular permissions.

Authentication Flow

• Client calls login(username, password) and gets an AuthToken
• The AuthToken is maintained on the server
• The client sends the AuthToken with each RPC request

Granting Access

• JMX operations
  • grantAccess(username, password) --> create/edit creds
  • revokeAccess(username) 
• DO NOT allow the removal of "root" user

AccessControlManager

The AccessControlManager is maintained at the server level and is used to guard access to the Engine.

• Map<String, ByteBuffer/byte[]> credentials (user -> password)
• Map<AccessToken, String> sessions (token -> user)

TODO: How to handle token expiration?? Should that be included in the AccessToken object?

Each time the service sees a token, it checks to see if exists in the db and is not expired and matches the username

Server Based Security

Access control should be managed at the Server level (instead of the Engine).

• The Engine manages how data is stored. Access controls should not alter the way data is stored
• If the Engine doesn't know about access control, then we can more easily replace the Engine in the future

Open Questions

1. Should we require user authentication to invoke managed operations from the command line?
   1. These operations do not go through the client, so we would have to a) create special JMX hook into the server based authentication scheme or b) create a separate authentication scheme for managed operations.
2. How should we hash passwords?
   1. Do we need a master serverKey hash? How is this generated and where is it stored?
      1. No. This doesn't add any additional security since the master password would be stored in prefs file and therefore accessible to someone with access to the server. We could encrypt the master password, but then we'd need to rely on the MAC Address which can change and we'd have to rehash every password if the master key ever changed. All of this adds a complexity overhead that isn't a good tradeoff since we don't actually end up with any additional security. 
   2. Do we need salt per user?
      1. Yes. Choose a random salt per user and store that alongside the password.
   3. Which hash algorithm should we use?
      1. SHA-512
3. Do we need to associate a fingerprint (ip address, etc) with each AccessToken?
   1. How would we get this info server side? Does the client need to pass it along when logging in?