Документация для Ocelot - Аутентификация

Я пытаюсь изучить и рассмотреть возможность разделения моего текущего api asp.net на кучу более мелких API, чтобы попытаться создать приложение для микросервисов (в основном для учебных целей). Я использую Ocelot в качестве шлюза, и я обнаружил, что Ocelot удобен и прост в настройке. Однако мне трудно найти подходящую документацию, например, о том, как добавить аутентификацию, поскольку ocelot.readthedocs.io кажется скудным в этом отношении. Мне трудно понять, следует ли мне использовать методы регистрации и входа в API шлюза или по-прежнему хранить их отдельно в микросервисе, который содержит базу данных пользователей? Может быть, мне следует подключить API моего шлюза к базе данных пользователей для прямого взаимодействия? (похоже, что это противоречит цели микросервисов).

Для меня также кажется небезопасным аутентифицировать только перенаправления по сравнению с аутентификацией методов http, как в монолитном приложении. Но я мог просто упустить из виду главное. В противном случае, если вы, ребята, знаете какой-либо отличный источник информации, это было бы здорово, так как мне трудно найти артсилы, учебные пособия, курсы или что-либо в этом роде для микросервисов ocelot и asp.net.


asp.net asp.net-core asp.net-web-api ocelot
person Arthos    schedule 10.03.2020    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Мы применяем тот же подход с использованием микросервисов, и мы решили его, перезаписав стандартное промежуточное ПО для проверки подлинности ocelot.

В автозагрузке (ядро .net) в разделе Configure мы реализовали это следующим образом:

 public async void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            OcelotPipelineConfiguration ocelotConfig = new OcelotPipelineConfiguration
            {
                AuthenticationMiddleware = async (ctx, next) =>
                {
                    try
                    {
                        AuthenticationClient.Authenticate(Configuration, ctx.HttpContext, new List<string>());
                        IEnumerable<string> allowedRoles = ctx.DownstreamReRoute.RouteClaimsRequirement.Select(e => e.Value).ToList();
                        if(allowedRoles != null && allowedRoles.Count() > 0)
                        {
                            string userId= AuthenticationClient.Authenticate(Configuration, ctx.HttpContext, allowedRoles);
                            ctx.DownstreamReRoute.AddHeadersToDownstream.Add(new AddHeader("userId", userId));
                        }
                    }catch(ApiGateway.Core.Exceptions.ForbiddenException e)
                    {
                        ctx.Errors.Add(new ApiGateway.WebApi.Exceptions.ForbiddenException(e.Message, Ocelot.Errors.OcelotErrorCode.UnauthorizedError));
                    }
                    catch(Exception e)
                    {
                        ctx.Errors.Add(new UnauthenticatedError(e.Message));
                    }
                    await next.Invoke();
                },
                AuthorisationMiddleware = async (ctx, next) =>
                {
                    await next.Invoke();
                }
            };

Объяснение:

Сначала пользователь проходит аутентификацию с использованием bearer-jwt-token (или Basic) из http-заголовка.

Затем прочтите разрешенные роли / разрешения (у нас есть группы активного каталога в качестве ролей) в Ocelot-Settings (Раздел RouteClaimsRequirement).

Если у пользователя есть одна из разрешенных ролей / разрешений, мы получаем userId и добавляем его в заголовок http-запроса, который пересылается соответствующей службе. Итак, целевая служба знает пользователя.

To me, it also sounds kind of insecure to only authenticate the reroutes,

Обычно сами микросервисы недоступны напрямую и развертываются на уровне сервера. Доступ к ним разрешен только API-шлюзу. Преимущество в том, что вашим микросервисам не нужно заботиться об аутентификации, авторизации и т. Д.

Надеюсь, это поможет прояснить ваш вопрос.

person SNO    schedule 12.03.2020