Как получить токен через API из IBM App ID при поддержке SAML? - PullRequest
Новая
       40

Как получить токен через API из IBM App ID при поддержке SAML?

0 голосов
/ 04 июня 2019

Я пытаюсь использовать App ID для аутентификации / авторизации пользователя в службе, работающей в Kubernetes, из инструмента CLI.

Я предоставил идентификатор приложения и настроил провайдера идентификации SAML.Я добавил приложение и получил идентификатор клиента, идентификатор клиента и секрет клиента.Я также добавил аннотацию appid-auth к определению входа Kubernetes.

В соответствии с документацией здесь https://cloud.ibm.com/docs/services/appid?topic=appid-obtain-tokens, она должна быть довольно прямой через скручивание, но я получаю Error - cloud directory is OFF.

Вот пример с учетными данными X'd. 

$ curl -iX POST \
> https://us-south.appid.cloud.ibm.com/oauth/v4/XXXX/token \
> -H 'Authorization: Basic XXXXXXXXX' \
> -H 'Content-Type: application/json' \
> -H 'Accept: application/json' \
> -d '{"grant_type":"password","username":"testuser@ibm.com","password":"testuser"}'
HTTP/2 403
date: Tue, 04 Jun 2019 17:20:54 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d8fb55f6b30555b81f64b3c3e40bbf8f71559668853; expires=Wed, 03-Jun-20 17:20:53 GMT; path=/; domain=.us-south.appid.cloud.ibm.com; HttpOnly
x-dns-prefetch-control: off
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=15552000; includeSubDomains
x-download-options: noopen
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
surrogate-control: no-store
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate
pragma: no-cache
expires: 0
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4e1b948028aec1cf-IAD

Error - cloud directory is OFF

Если я использую "grant_type":"client_credentials", он возвращает получить токен доступа, но мне нужен токен идентификации, чтобы приложение могло делатьавторизация на основе пользователя.

Я попытался использовать версию «web» в определении входа, и веб-перенаправление работает нормально.Так что я знаю, что SAML настроен правильно.

1 Ответ

0 голосов
/ 05 июня 2019

Здесь вы смешиваете несколько разных концепций.

Проверка подлинности SAML работает путем предоставления пользователю пользовательского интерфейса входа.Пользователь должен заполнить адрес электронной почты / пароль (или какие-либо учетные данные), а затем вернуться в приложение.Суть в том, что рабочий процесс аутентификации SAML подразумевает пользователя-пользователя, который может взаимодействовать с браузером для ввода учетных данных.Для достижения федерации SAML через OpenID Connect (на основе которого используется идентификатор приложения протокола) используется тип grant_type с именем authorization_code.Этот рабочий процесс также подразумевает предоставление пользователю пользовательского интерфейса для входа.Поскольку аутентификация SAML не может использоваться без предоставления пользователю пользовательского интерфейса, вы не можете использовать только подход API для аутентификации пользователей.С SAML вы должны использовать grant_type=authorization_code, который будет правильно работать только в браузерах (если вы не выполняете html-очистку, что не рекомендуется).

"grant_type = client_credentials" работает по-другому.Он предназначен для неинтерактивных сценариев, в которых не задействованы пользователи.SAML используется для аутентификации пользователей, client_credentials используется для аутентификации приложений / сервисов.

Ознакомьтесь с технологиями В видео Hood в Учебниках по идентификатору приложения на youtube объясняются различия между различными рабочими процессами - https://www.youtube.com/playlist?list=PLbAYXkuqwrX2WLQqR0LUtjT77d4hisvfK

...