Requirements for authorization management

[dmgav]

This issue contains a minimum list of authorization data required by different modules of the queue server. The purpose is to find appropriate way to store this data on a secured system. The list could be expanded with more data to incorporate future functionality. It is undesirable to remove any items from the list, since it will effectively disable already existing features of the Queue Server. It is assumed that the system already provides secure user authentication and the server can use user ID to access the data.

• The list of users currently allowed to access the beamline. The scope of access is determined by the API access group name, which is set separately (see below). For example, some users may be allowed to monitor execution of plans, but not control the beamline. Adding and removing users from the list should not change API access group name.

• API access group name (string) for each user for each beamline. The HTTP server can provide fine-grained control of user access to API. The API are split into logical groups and the scope for each user may include any combination of those groups (see the examples of scopes for the default groups used in demo

  bluesky-httpserver/bluesky_httpserver/database/core.py

  Lines 27 to 85 in 5277d51

  	db.add(
  	Role(
  	name="user",
  	description="Default Role for users.",
  	scopes=[
  	"read:queue",
  	"read:history",
  	"read:resources",
  	"read:config",
  	"read:monitor",
  	"read:console",
  	"read:status",
  	"read:lock",
  	"write:queue:edit",
  	"write:queue:control",
  	"write:manager:control",
  	"write:plan:control",
  	"write:execute",
  	"write:history:edit",
  	"write:permissions",
  	"write:scripts",
  	"write:config",
  	"write:lock",
  	"write:unsafe",
  	"apikeys",
  	],
  	),
  	)
  	db.add(
  	Role(
  	name="admin",
  	description="Role with elevated privileges.",
  	scopes=[
  	"read:queue",
  	"read:history",
  	"read:resources",
  	"read:config",
  	"read:monitor",
  	"read:console",
  	"read:status",
  	"read:lock",
  	"write:queue:edit",
  	"write:queue:control",
  	"write:manager:control",
  	"write:plan:control",
  	"write:execute",
  	"write:history:edit",
  	"write:permissions",
  	"write:scripts",
  	"write:config",
  	"write:lock",
  	"write:unsafe",
  	"admin:apikeys",
  	"read:principals",
  	"metrics",
  	],
  	),
  	)
  	db.commit()

  ).

• Definitions of scopes for API access user groups (dictionary) for each beamline. While it is possible to define fixed set user groups in the source code to cover the basic access needs, it is likely that beamline staff may request more fine grained control with ability to add new groups and change scopes for the existing groups.

• Plan/device access group name (string) for each user for each beamline. This name is different from API access group name and determines which plans and devices the user can access. The user groups may be defined in a YAML file in profile_collection directory and automatically loaded by the Queue Server at startup or stored in the database and uploaded to the Queue Server using API. The plan/device access groups are defined mostly for convenience (avoid errors due to accidental access and reduce clutter in lists of allowed plans and devices and related GUI menus), may be changed dynamically if needed and are not considered secured information.