Product-apim: Поддержка базовой аутентификации для подписчиков

Недавно выпущенный APIM 3.0.0 поддерживает базовую аутентификацию. В настоящее время мы используем его в нашей среде.

Да для конечных точек серверной части. Для Api мне не удалось найти вариант.

API Publisher -> Конфигурации времени выполнения -> Безопасность на уровне приложения

@ Tomas-Mrazek правильно, теперь мы также поддерживаем базовую аутентификацию для клиентов API. Вы можете включить опцию Basic на уровне безопасности приложения, как показано выше. Это позволит потребителям API вызывать этот API, используя комбинацию имени пользователя и пароля.

Ладно, похоже, я искал то же место. Просто протестировал, и он работает.

Это вызывает больше вопросов.

Как подписки работают с базовой аутентификацией? Кажется, любой пользователь может вызывать любой Api, независимо от подписок? Есть ли способ «назначить» пользователей конкретным приложениям, чтобы они могли вызывать только API, на которое подписано приложение?

Если и Prod, и Sandbox используют один и тот же шлюз, как определяется, какой из них вызывается при выполнении базовой аутентификации?

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

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

Как подписки работают с базовой аутентификацией? Кажется, любой пользователь может вызывать любой Api, независимо от подписок? Есть ли способ «назначить» пользователей конкретным приложениям, чтобы они могли вызывать только API, на которое подписано приложение?

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

Вы не можете назначать пользователей приложениям, потому что это работает противоположным образом - приложения принадлежат пользователю. Если вам нужен более детальный контроль, создайте роли в консоли / carbon и назначьте их пользователям. В издателе API перейдите в настройки API, измените видимость на портале разработки на определенную роль. Затем создайте области с определенной ролью для каждого ресурса, назначьте эту область ресурсу, включите безопасность. Подписанные пользователи могут вызывать API, но без назначения пользователю роли они не могут вызывать какой-либо защищенный ресурс.

Если и Prod, и Sandbox используют один и тот же шлюз, как определяется, какой из них вызывается при выполнении базовой аутентификации?

Хороший вопрос. Я не знаю ответа.

Кстати, это не сработает с ключом потребителя и секретом. Конечная точка указывается во время генерации / токена AFAIK.

Привет, @ Tomas- Mrazek и

OAuth2 - мы подписываем приложение на Api. На основе ключа и секрета мы знаем Приложение и Среду. Итак, чтобы позволить приложению использовать Api, все, что нам нужно сделать, это подписаться на него. Затем любой пользователь может вызвать этот Api, учитывая, что он знает ключ и секрет.

Статические ключи Api - здесь мы знаем ключ, и это дает достаточно информации, чтобы знать, какое приложение вызывает Api и какую среду оно использует. Концепция подписки приложения на Api для его использования по-прежнему применяется. Нам нужно только подписать приложение на Api.

Обычная аутентификация, как сейчас - я назову ее «пользовательская базовая аутентификация». Он полностью отказывается от концепции приложения и подписки и требует использования другой концепции (пользовательские разрешения) и различных инструментов, таких как использование Carbon admin вместо Publisher или Store / DevPortal. И он не может отличить рабочую среду от среды песочницы, когда для обеих используется один шлюз. Это также дает дополнительный уровень сложности для настройки и администрирования. Теперь недостаточно взглянуть на список приложений, на которые вы подписаны, нужно также перейти в админку углерода и посмотреть пользователей и разрешения. И если я хочу ограничить рейтинг одного конкретного приложения для Api или иметь разные уровни подписки, я не могу сделать это для пользователя.

Я бы назвал "правильным" способом поддержки базовой аутентификации следующее:

Базовая аутентификация на уровне приложения - мы исключаем пользователя из концепции (например, со статическими ключами) и вместо этого используем аутентификацию приложения. Приложению по-прежнему необходимо подписаться на Api. Consumer Key и Consumer secret используются в качестве учетных данных базовой аутентификации. Таким образом, мы сохраняем концепцию подписки на App / Api, можем продолжать использовать те же инструменты, что и для всего остального (publisher / devPortal, нет необходимости в Carbon Admin), и мы знаем, какое приложение использует какой Api и какая среда на основе ключей.

Как туда добраться?

Есть два варианта. Либо измените текущую базовую реализацию на предложенную выше, либо внедрите новую под названием «Базовая проверка подлинности приложения».
Существует также третий вариант, поддерживающий как пользователь / пароль, так и ключ / секрет в существующей базовой аутентификации, но это самый грязный вариант.

Базовой реализации Auth недостаточно. Например, вы можете ограничить видимость API на портале разработчиков на основе ролей ->, которые необходимо создать и связать с пользователем через консоль Carbon.

Привет, @ Tomas-Mrazek и @markokocic
Спасибо за ваши предложения, пожалуйста, найдите мои ответы в строке.

Как подписки работают с базовой аутентификацией? Кажется, любой пользователь может вызывать любой Api, независимо от подписок? Есть ли способ «назначить» пользователей конкретным приложениям, чтобы они могли вызывать только API, на которое подписано приложение?

Базовая поддержка аутентификации для клиентских запросов не требует наличия подписок. Если создатель API включил поддержку базовой аутентификации для определенного API, этот API можно вызывать без подписки на этот API (через приложение).
и @markokocic да, как работает подписка, An Application subscribed to an API .

Кроме того, с авторизацией Baisc:
вы по-прежнему получаете:

• Регулирование уровня ресурсов или уровня API
• Проверка объема ресурсов

вы не получите:

• Регулирование уровня подписки
• Дифференциация производственной среды и среды песочницы

Если и Prod, и Sandbox используют один и тот же шлюз, как определяется, какой из них вызывается при выполнении базовой аутентификации?

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

@ Томас-Мразек

Конечная точка указывается во время генерации / токена AFAIK.

Нет, конечные точки (продукт и песочница) определяются создателем API при создании API, потребители API могут предоставить URL обратного вызова для приложения, если они хотят использовать типы грантов на основе перенаправления (i: e неявно)

@markokocic относительно

Базовая проверка подлинности на уровне приложения

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

Базовая проверка подлинности на уровне приложения

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

@tmkasun
Да, можно использовать обычную проверку подлинности для создания токена с использованием учетных данных клиента. Вы используете что-то вроде этого:

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Однако для использования API ваш потребитель по-прежнему должен уметь:

• сгенерируйте токен, используя метод выше
• установите его как HTTP-заголовок «Авторизация» с носителем и токеном для фактического запроса API.
• в конечном итоге позаботьтесь об истечении срока действия токена и обновите

Это нормально, если программист запрограммирует вашего потребителя или у вас есть поставщик, который может это сделать. Как описано, проблема заключается в том, что многие устаревшие корпоративные клиенты не настраиваются. Например, в SAP, если вы хотите использовать внешнюю службу, единственное, что вы можете установить, - это URL-адрес и, возможно, имя пользователя и пароль для базовой аутентификации. Там у вас нет возможности получить токен или установить пользовательские заголовки.

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

Что-то вроде:

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

Это позволило бы мне по-прежнему использовать ту же модель подписки App to API единообразно, без необходимости создавать, настраивать и управлять пользователями.

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

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

РЕДАКТИРОВАТЬ: Теперь, когда я думаю об этом, возможно, более ясным именем будет Базовая аутентификация на основе учетных данных клиента для API.