Agent applies token based authentication for REST web service interface

Handling of access tokens by Agent

• The Agent can be configured to require an access token to be forwarded with each REST web service call.
  • No access token is required for the REST web service path /jobscheduler/agent/api or /jobscheduler/agent/api/overview that can be used by any client to check if an Agent is up and running. JS-684 specifies active checks that are performed by a system monitor such as Nagios or clones that are handled without authentication token.
  • No access token is required for Agents that are not assigned an access token file, see below.
• The Agent verifies an incoming access token against the list of tokens that is provided with the file jobscheduler_agent_access_tokens.
  • If the incoming token exists then the web service call is served.
  • Otherwise the Agent will deny this call, respond with an HTTP error code 401 and log an error.
• The plain text file jobscheduler_agent_access_tokens
  • stores each access token in a separate line.
  • is declared to the Agent by use of the command line parameter -access-tokens

Handling of access tokens by Master

• The JobScheduler Master forwards an access token with each HTTP request to the respective Agent.
• The JobScheduler Master expects the access token to be specified with the process class that indicates the Agent instance, see JS-1590.

Handling of access tokens by Browsers

• For use with browsers HTTP basic authentication is enforced by the Agent if an access token file has been assigned on start-up of the Agent.
  • The browser shows a pop up window that requests input of
    • the user name access-token which represents a constant value and
    • the password that is specified by the access token.