Create SingleGroupResourceAccessControl

[RafaelLyra8]

This resource access control returns the first user group setted to the current user on the API access policy.
Configuration file example in which the user1 will have access to 'user' group plans and devices and user2 will have access to 'expert' group plans and devices:

api_access:
  policy: bluesky_httpserver.authorization:DictionaryAPIAccessControl
  args:
    users:
      user1:
        roles:
          - user
       user2:
        roles:
          - expert
          - admin
resource_access:
  policy: bluesky_httpserver.authorization:SingleGroupResourceAccessControl
  args:
    default_group: root

Description

Motivation and Context

Allow different users to have access to different plans depending on their specific uses. This is mainly intended to give a broader range of plans and devices for the beamline staff while hiding most of the auxiliary plans from the beamline users.

Summary of Changes for Release Notes

Added the SingleGroupResourceAccessControl class for resource control.

Added

A new resource access mode, for showing only the logged user allowed resources by its first setted group in the api access policy.

How Has This Been Tested?

This was tested initially with a GUI that uses the bluesky_widgets library to communicate with a local HTTP server instance, with a DictionaryAuthenticator as authenticator and a DictionaryAPIAccessControl as api_access. This test included anonymous access users to interact with the GUI.
Further tests using LDAPAuthenticator as authenticator and ServerBasedAPIAccessControl as api_access will still be conducted.

[dmgav]

@RafaelLyra8 Thank you for contributing to the project. In the current implementation of authentication and access control, the roles and group names are intentionally decoupled, i.e. access to API and access to plans and devices are set separately for each user. This allows to split users into groups based on their scientific needs, not simply based on their 'administrative' role. In production system both group names and API access roles are stored in a database and the support is implemented in custom, facility-specific classes. Do you have the use case where you would prefer to link the roles and group names?

[RafaelLyra8]

@dmgav I thought this implementation for a simpler use case in which the plans and devices access are directly linked to if they are a user or an expert. And I linked the group and roles as to simplify the implementation for this case, but if you think it would be better to leave it decoupled, I could try to implement that way.