Access Control Gateway is an access control Plugin component of feature registry API. It can work with different type of backend registry. When user enables this component, registry requests will be validated in a gateway as below flow chart:

flowchart TD
    A[Get Registry API Request] --> B{Is Id Token Valid?};
    B -- No --> D[Return 401];
    B -- Yes --> C{Have Permission?};
    C -- No --> F[Return 403];
    C -- Yes --> E[Call Downstream API*];
    E --> G{API Service Available?}
    G -- No --> I[Return 503]
    G -- Yes --> H[Return API Results]

If Access control plugin is NOT enabled, the flow will directly Call Downstream API*.

• For all get requests, check read permission for certain project.
• For all post request, check write permission for certain project.
• For all access control management request, check manage permission for certain project.
• In case of feature level query, will verify the parent project access of the feature.
• Registry API calls and returns will be transparently transferred.

Users needs to create a userroles table with schema.sql at the very first place. The process will be similar with SQL Registry bacpac initialization.

In current version, user needs to manually initialize userroles table in SQL database with schema.sql and insert global admin roles. You can add [your-email-account] as global admin with the following SQL script in Azure portal query editor

insert into userroles (project_name, user_name, role_name, create_by, create_reason, create_time) values ('global', '[your-email-account]','admin', '[your-email-account]', 'Initialize First Global Admin',  getutcdate())

When a feathr project is created though rbac protected registry API, default project admin role will be assigned to the creator. Admin roles can add or delete roles in management UI page or through management API under certain scope.

ENABLE_RBAC needs to be set to deploy a registry backend with access control plugin.

Please notice that User Role records are NOT case sensitive. All records will be converted to lower case before saving to database. Supported scenarios status are tracked below:

• General Foundations:
  • Access Control Abstract Class
  • API Spec Contents for Access Control Management APIs
  • API Spec Contents for Registry API Access Control
  • Separate Registry API and Access Control into different implementation
  • A docker file to contain all required component for deployments
• SQL Implementation:
  • userroles table CRUD through FastAPI
  • userroles table schema & test data, could be used to make .bacpac file for SQL table initialize.
  • Initialize default Project Admin role for project creator
  • Initialize default Global Admin Role for workspace creator
• UI Experience
  • management page for project admin to make CUD requests to userroles table
  • Use id token in Management API Request headers to identify requestor
• Future Enhancements:
  • Support AAD Application token
  • Support OAuth tokens with email attributes
  • Functional in Feathr Client
  • Add Access Control Dev Guide (include deployment tips)
  • Add Access Control User Guide (UI & Client Experience)
  • Support AAD Groups
  • Support Other OAuth Providers

Get userrole records of projects that requestor has manage access.

• Response Type: UserRole

Create a new role assignment

• Request Params:
  • project: project name or global
  • user: user email or app id
  • role: admin or producer or consumer
  • reason: create reason

Delete an existing role assignment

• Request Params:
  • project: project name or global
  • user: user email or app id
  • role: admin or producer or consumer
  • reason: delete reason