Я слышал, что для .NET8 Microsoft подарила нам полностью «фиксированную» настройку аутентификации и авторизации.
Теперь, когда я создаю приложение Blazor на основе шаблонов, оно создает целую кучу страниц администрирования пользователей, включая вход в систему и т. д., и есть миграция базы данных, которую вы можете запустить, чтобы создать для нее соответствующую серверную поддержку. И это прекрасно работает: я могу прямо из коробки добавлять пользователей, входить в систему и защищать страницы с помощью флага [Аутентификация].
Первая проблема, с которой я столкнулся, заключается в том, что я не хочу использовать Entity Framework и не хочу использовать MS SQL Server. Но это проблема в другой раз.
Моя более широкая проблема заключается в том, что этот нестандартный интерфейс, представленный в шаблоне проекта Blazor, не пытается реализовать одну из типичных архитектур, где у вас есть приложение Blazor для внешнего интерфейса, база данных для внутреннего интерфейса и API. который находится между получением и ответом на запросы.
В этой схеме, которую я хочу использовать, удостоверение не должно обрабатываться непосредственно приложением Blazor. Вместо этого на самом деле это должен делать WebAPI, поскольку именно он имеет доступ к серверной части базы данных.
Но если я использую шаблоны для создания проекта API .NET8, Microsoft будет придерживаться предыдущего метода аутентификации AzureAD (из предыдущих версий .NET) и не будет использовать какие-либо новые элементы удостоверений, которые вы получаете вместе с приложением Blazor.
Хорошо, возможно, я смогу увидеть, что они делают в приложении Blazor, и вместо этого реализовать все это на стороне API. Но теперь я задаюсь вопросом, не иду ли я против течения и делаю что-то, чего Microsoft не собирается делать. По сути, я беспокоюсь, что заблудился в море и делаю что-то не так.
Существует еще одна сложность: даже если я реализую всю эту идентификацию в API, мне все равно нужно будет вернуть какой-то объект идентификации в приложение Blazor, поскольку ему также необходимо знать, в порядке ли вход пользователя и какие роли у них есть. Я могу представить себе несколько способов вызова конечной точки API для входа в систему из приложения Blazor и возврата подходящего объекта идентификации в приложение Blazor. Но как насчет возможности атак через посредников, когда кто-то отправит свой собственный объект идентификации? Защищено ли оно из-за соединения https:// между приложением Blazor и WebAPI?
Вкратце мой вопрос: является ли моя настройка WebAPI для идентификации, возврат объекта идентификации в Blazor типичным решением или я иду по неправильному пути?
Я всегда задавал себе один и тот же вопрос: почему шаблоны и даже документация Microsoft так мало предлагают тем, кто хочет иметь более готовую к использованию систему?
Подход, который я выбрал уже некоторое время, заключается в следующем:
Предоставление полного объяснения того, как сделать вышеизложенное, выходит за рамки SO-ответа... если вы не можете его найти, я могу попытаться составить сообщение в блоге.
Я надеюсь, что это, по крайней мере, будет полезно и подтолкнет вас в правильном направлении.
ОБНОВЛЕНИЕ: это моя попытка дать дополнительные рекомендации о том, как действовать.
Эту функцию я использую для извлечения всей важной информации в запись, которую мы называем BackendSecurityContext:
public class EasyAuthHeadersAzureFunctionsSecurityContextFactory : IAzureFunctionsSecurityContextFactory
{
public const string HeaderName_PrincipalID = "x-ms-client-principal-id";
public const string HeaderName_PrincipalName = "x-ms-client-principal-name";
public IBackendSecurityContext CreateSecurityContext(IEnumerable<ClaimsIdentity> claimsIdentities, ImmutableDictionaryOfSet<string, string> httpRequestHeaders)
{
// Supporting documentation can be found here: https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-user-identities#access-user-claims-in-app-code
var idStr = httpRequestHeaders[HeaderName_PrincipalID].SingleOrDefault();
var name = httpRequestHeaders[HeaderName_PrincipalName].SingleOrDefault();
var result = new BackendSecurityContext(
idStr is null ? null : Guid.Parse(idStr), // PrincipalID
name, // PrincipalName
!string.IsNullOrEmpty(idStr), // IsAuthenticated
[], // PrincipalClaims
ImmutableListWithSequenceEquality<string>.Empty // Roles
);
return result;
}
}
Примечание. По моему мнению, все это должно быть описано на одной странице документации Microsoft в качестве комплексного руководства по серьезной/готовой к производству разработке и развертыванию веб-приложения, но я никогда не нашел такой страницы. Если кто-то это сделает, ему следует просто заменить мой ответ ссылкой! :-)
Я постарался добавить больше деталей. Все еще может быть сложно заставить все это работать, размещая правильные идентификаторы в нужных местах... но, надеюсь, это поможет.
Спасибо! Кажется на мой вопрос нет ни одного ответа, но поскольку Вы дали наиболее полный ответ, я отметил его как ответ. Я постараюсь разобраться с этим в качестве POC и посмотреть, как у меня получится. Ваше здоровье. Я ценю время.
Я думаю, что половина людей в MS больше не знают, что они делают, постоянная отток пользователей для аутентификации определенно предполагает это! Проблема открыта на github, где есть пример использования OpenIDdict, а также пример использования JWT для внешнего интерфейса с аутентификацией ASP сзади. Хотя это все беспорядок.
В Openiddict есть сообщение в блоге о том, как сделать приложение Blazor аутентифицированным по вашему желанию — с атрибутами авторизации и т. д.
Отлично, я проверю это, спасибо — и приятно знать, что я борюсь с этим не потому, что заблудился, а потому, что в игре есть настоящая проблема.
Спасибо за ваш вклад. Я также осознаю, что мой вопрос сложно вписать в критерии приемлемости вопросов StackExchange. Ваше здоровье.