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

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

0 голосов
/ 10 марта 2020

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

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

1 Ответ

0 голосов
/ 12 марта 2020

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

При запуске (. net core) в разделе 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 (или Basi c) из http-заголовка.

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

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

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

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

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

...