OAUTH2 + OpenID Connect, какую конечную точку использовать для добавления некоторых областей для пользователя? - PullRequest
Новая
       27

OAUTH2 + OpenID Connect, какую конечную точку использовать для добавления некоторых областей для пользователя?

0 голосов
/ 06 марта 2019

У меня есть:

  1. Клиентское приложение весенней загрузки с некоторыми общедоступными конечными точками и частными конечными точками, которым требуется @ PreAuthorize ("# oauth2.hasScope ('resource.read')") например
  2. У меня есть внешний сервер авторизации: Cloudfoundry UAA
  3. У меня есть внешний поставщик OIDC, связанный с UAA. Я могу использовать его для аутентификации человека, я получаю Person_ID от ID_Token отэтот внешний поставщик OIDC
  4. Теперь мне нужно изменить основной код UAA, чтобы реализовать мою логику использования этого Person_ID и поиска эквивалентного пользователя из LDAP, который использует тот же Person_ID, а затем мне нужно будет добавить его группы пользователей в токендля клиента.(Я сделал это в настоящее время в конечной точке / userinfo)

Итак, я проделал эту логику в конечной точке / userinfo, когда клиент получает токен доступа (от клиента, перенаправленного на UAA, от UAA кOIDC для AUTH, затем снова для токена, а затем этот токен отправляется клиенту, теперь клиент может взять токен и запросить / userinfo, который затем будет иметь свои роли пользователя)

Это плохая логика?Должен ли я как-то добавить реализацию LDAP (шаг 4) в токен доступа?

1 Ответ

0 голосов
/ 06 марта 2019

Действительно, как это часто бывает с вопросами о дизайне, это зависит.

Необходимо помнить, что OIDC и связанный с ним id_token предназначены для аутентификации. Обычно ответ /userinfo на утверждения о том, кто пользователь. Частью личности пользователя может быть их роль.

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

Подумайте, какие решения нужно будет принять этому клиенту. Может быть, он сможет выбирать, какие страницы он может показывать, основываясь на ролях, которые он вывел из ответа /userinfo.

Подумайте, с чем этот клиент будет общаться. Может быть, он будет общаться с сервером ресурсов. Если клиент передает access_token, полученный во время входа в систему, то этот токен должен указывать, что клиент имеет право делать.

...