Ankur Ramanuj Ответов: 1

Как сделать API открытым для внутреннего и защищенным от внешнего


Привет,

У меня есть один .Net core project for API и у меня есть требование внешнего и внутреннего использования API. Проще говоря, мне нужно сделать API открытым для внутренних пользователей и защищенным для внешних пользователей. Когда внутренний пользователь попадает в конечную точку, он не должен запрашивать какие-либо учетные данные, но если внешний пользователь попадает в конечную точку, API должен запрашивать безопасность.

Как я могу этого достичь?

Что я уже пробовал:

Я пытался изучить службы azure, но не могу этого понять.

F-ES Sitecore

Что вы определяете как "внутренний пользователь" и "внешний пользователь"?

Ankur Ramanuj

Это главный вопрос бродящий у меня в голове
1) Как идентифицировать пользователя
2) Как предотвратить на одном url-адресе

F-ES Sitecore

Что вы считаете "внутренним" пользователем и "внешним" пользователем? Это не термины со стандартными определениями, поэтому ваша концепция внутреннего и внешнего может отличаться от чьей-то еще.

Ankur Ramanuj

Внутренний пользователь, предназначенный для меня, - это пользователи из моей организации или, другими словами, внутренние разработчики.
Внешние пользователи-это те, кому я продаю свои API, то есть кто-то вне организации.


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

Как я могу этого достичь?

1 Ответов

Рейтинг:
1

MadMyche

Есть несколько возможностей для использования.

Первый метод будет основан на какой-то фильтрации IP-адресов.
1. API должен быть написан, чтобы потребовать маркер аутентификации.
2. входящие запросы будут перехвачены до конечной точки, и если входящий запрос соответствует вашему корпоративному IP-адресу, вы можете ввести фиксированный токен, поэтому им не нужно будет проходить аутентификацию.
Я лично считаю что это набор хаков и бинтов и не рекомендую

Второй способ заключается в создании отдельных конечных точек для внутренних и внешних пользователей; одна из них нуждается в аутентификации, а другая-нет. Эти два будут простыми оболочками, вызывающими основные методы API.


Richard Deeming

Конечно, неаутентифицированная конечная точка без каких-либо ограничений на то, кто может ее вызвать, будет называться "безопасность по неизвестности". И мы все знаем, насколько это "безопасно"! :)

MadMyche

Хотя я не одобряю такого рода вещи и буду бороться с ними, иногда это именно то, что мы там обнаруживаем.