В обход шлюза Ocelot API - PullRequest
Новая
       91

В обход шлюза Ocelot API

0 голосов
/ 14 мая 2019

У меня есть API-шлюз, в данном случае он называется Gateway.Api.В классе Startup у меня есть следующее: 

public IConfiguration Configuration { get; }

    // This method gets called by the runtime. Use this method to add services to the container.
    // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=398940
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddOcelot(Configuration);
        services.AddMvc();

        var appSettingSection = Configuration.GetSection("AppSettings");
        services.Configure<AppSettings>(appSettingSection);

        var appSettings = appSettingSection.Get<AppSettings>();
        var key = Encoding.ASCII.GetBytes(appSettings.Secret);

        services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
            .AddJwtBearer(options =>
            {
                options.SaveToken = true;
                options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateIssuerSigningKey = true,
                    IssuerSigningKey = new SymmetricSecurityKey(key),
                    ValidateIssuer = false,
                    ValidateAudience = false
                };
        });
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        app.UseAuthentication();
        app.UseOcelot().Wait();
        app.UseMvc();
    }

Как вы можете видеть, он определяет схему аутентификации.

Использование Ocelot У меня есть следующий файл конфигурации для моего Gateway.Api: 

{
  "ReRoutes": [
    {
      "DownstreamPathTemplate": "/api/customer",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 50366
        }
      ],
      "UpstreamPathTemplate": "/api/customer",
      "UpstreamHttpMethod": [ "Get" ],
      "AuthenticationOptions": {
        "AuthenticationProviderKey": "Bearer",
        "AllowedScopes": []
      }
    },
    {
      "DownstreamPathTemplate": "/api/user/authenticate",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 50353
        }
      ],
      "UpstreamPathTemplate": "/api/user/authenticate",
      "UpstreamHttpMethod": [ "Post" ]
    }
  ],
  "GlobalConfiguration": {
    "UseServiceDiscovery": false
  }
}

Когда я пытаюсь получить доступ к http://localhost:50333/api/customer (Gateway.Api имеет порт 50333) без токена, я получаю ответ 401, который подтверждает, что файл конфигурации, а такжеаутентификация работает.

Помимо микросервиса Customer, у меня также есть микросервис Identity, который позволяет пользователям проходить аутентификацию, используя действительные имя пользователя и пароль, которые затем выдают токен.Используя этот токен, чтобы затем позвонить в отдел обслуживания клиентов, я получаю успешный ответ (200 OK).

Теперь по какой-то причине, если я обращаюсь в службу поддержки клиентов напрямую без использования шлюза (поэтому http://localhost:50366/api/customer) Я могу получить успешный ответ без токена.

Нижемикросервис клиента: 

[Route("api/[controller]")]
public class CustomerController : Controller
{
    [HttpGet]
    public IEnumerable<string> Get()
    {
        var customers = new string[] {
            "test",
            "test"
        };

        return customers;
    }
}

Означает ли это, что я должен добавить схему аутентификации для каждого класса микросервиса Startup? Если да, разве это не перебор?

Что я сделалtry использует атрибут [Authorize] для действий в микросервисе Customer, однако это вызывает исключение, что их схема аутентификации по умолчанию отсутствует.

Ответы [ 2 ]

1 голос
/ 14 мая 2019

Это среда разработки, поэтому вы можете получить прямой доступ к URL. Ваша служба поддержки клиентов не имеет представления о шлюзе. В реальной производственной среде вы обычно выставляете только шлюз API, а остальные службы находятся за брандмауэром (частная подсеть). Только шлюз API имеет к ним доступ. Единственный способ получить доступ к сервисам - пройти через шлюз. Однако, если вы хотите предоставить услуги публично, тогда необходима индивидуальная аутентификация службы.

Независимо от того, что вы всегда хотите добавить аутентификацию в сервисы, которые хотите защитить, всегда полезно.

0 голосов
/ 23 мая 2019

Давайте разберемся в этом, почему мы используем API Gateway?

Существует множество причин для использования API Gateway, и одна из них:

Так что мы можем добавить аутентификацию на шлюзе API вместо добавления кода аутентификации во многих микро сервисах.

На компьютере с производственным сервером мы открываем только порт шлюза API для конечных пользователей, пользователи не имеют представления о том, где размещены другие службы micros, и не могут получить к ним доступ, пытаясь использовать другие порты, поскольку другие порты не открыты!

Также мы можем разместить сервисы micros только на другой машине, которая доступна только той машине, на которой размещен API-шлюз, путем внесения в белый список его IP-адреса.

Но в этом сценарии вы доверяете своим разработчикам и команде DevOps, иначе вы можете поставить дополнительную аутентификацию на микросервисе высокой стоимости, и эта аутентификация не будет отличаться от аутентификации, которую использовал конечный пользователь, здесь вы будете аутентифицировать API Шлюз.

...