Боб Белдербос: RBAC на основе базы данных с FastAPI и Azure Entra ID
Этот проект реализует сервис на FastAPI с гранулированным ролевым контролем доступа (RBAC) с использованием Azure Entra ID для аутентификации. Вместо жесткого кодирования политик доступа в каждом маршруте, эти политики хранятся в таблице базы данных. Это позволяет администраторам изменять разрешения пользователей без изменения и повторного развертывания кода приложения. Система использует Azure Entra ID для аутентификации пользователей и получения их ролей из утверждений JWT. Сопоставление ключей конечных точек с требуемыми ролями хранится в таблице SQLModel EndpointPermission.Ядром логики авторизации является функция require, которая используется как зависимость FastAPI. Эта функция извлекает требуемые роли для конечной точки из базы данных и проверяет, есть ли они у аутентифицированного пользователя. Если нет, выдается ошибка 403 Forbidden. Ключевая строка для конечной точки является единственным литералом, жестко закодированным в определении ее маршрута.Критически важно, что конечная точка для управления этими разрешениями сама защищена тем же механизмом RBAC, гарантируя, что только администраторы могут изменять правила доступа. Предусмотрены меры предосторожности, предотвращающие случайную отмену администраторами собственного доступа к конечной точке управления разрешениями, и гарантирующие, что назначения ролей никогда не будут пустыми. В статье освещаются две распространенные проблемы конфигурации Azure: использование токенов v1 вместо v2, что вызывает ошибки недопустимых токенов, и тот факт, что вложенные членства в группах не отражаются в ролях пользователей для прямого назначения.Проект также предоставляет рекомендации по эффективному тестированию логики авторизации. Тесты могут переопределять зависимости аутентификации и сеанса для использования фиктивных пользователей и баз данных SQLite в памяти, что позволяет проводить всестороннее тестирование без внешних зависимостей. Такая конструкция, вынося политику как данные, делает авторизацию динамичной и управляемой, в соответствии с принципом 12-факторного приложения. Автор подчеркивает необходимость различать логику кода и изменяемую политику.
EndpointPermission.Ядром логики авторизации является функцияrequire, которая используется как зависимость FastAPI. Эта функция извлекает требуемые роли для конечной точки из базы данных и проверяет, есть ли они у аутентифицированного пользователя. Если нет, выдается ошибка 403 Forbidden. Ключевая строка для конечной точки является единственным литералом, жестко закодированным в определении ее маршрута.Критически важно, что конечная точка для управления этими разрешениями сама защищена тем же механизмом RBAC, гарантируя, что только администраторы могут изменять правила доступа. Предусмотрены меры предосторожности, предотвращающие случайную отмену администраторами собственного доступа к конечной точке управления разрешениями, и гарантирующие, что назначения ролей никогда не будут пустыми. В статье освещаются две распространенные проблемы конфигурации Azure: использование токенов v1 вместо v2, что вызывает ошибки недопустимых токенов, и тот факт, что вложенные членства в группах не отражаются в ролях пользователей для прямого назначения.Проект также предоставляет рекомендации по эффективному тестированию логики авторизации. Тесты могут переопределять зависимости аутентификации и сеанса для использования фиктивных пользователей и баз данных SQLite в памяти, что позволяет проводить всестороннее тестирование без внешних зависимостей. Такая конструкция, вынося политику как данные, делает авторизацию динамичной и управляемой, в соответствии с принципом 12-факторного приложения. Автор подчеркивает необходимость различать логику кода и изменяемую политику.