Использование внешнего OpenID Connect Identity Provider для доступа к WSO2 Store - PullRequest
Новая
       5

Использование внешнего OpenID Connect Identity Provider для доступа к WSO2 Store

0 голосов
/ 18 января 2019

Я настраиваю экземпляр менеджера API WSO2 и хочу предоставить разработчикам доступ к страницам «хранилища» API, связав его с моим существующим сервером идентификации OpenID Connect (OpenAM). Я добавил конфигурацию OIDC в ​​файл конфигурации магазина ( wso2am-2.6.0 / репозиторий / развертывание / сервер / jaggeryapps / store / site / conf / site.json ) со всеми деталями авторизации , токены, конечные точки userinfo и т. д.

Когда пользователи нажимают на кнопку «Войти» в магазине, они корректно перенаправляют их в OpenAM для входа в систему и передают токен доступа обратно в приложение магазина. Я также гарантировал, что некоторые из требуемых утверждений возвращаются из конечной точки userinfo (например, предпочитаемое_имя_пользователя). Я также возвращаю претензию "groups", в которой перечислены группы, к которым пользователь должен относиться, например, в "subscriber".

Заявления, которые я возвращаю из userinfo: 

{  
   "address":{  
      "formatted":"My House"
   },
   "given_name":"Danny",
   "family_name":"Developer",
   "name":"Danny Developer",
   "preferred_username":"Danny Developer",
   "groups":[  
      "subscriber"
   ],
   "email":"adam.hatherly@nhs.net",
   "sub":"developer1"
}

Однако, что бы я ни пытался с утверждениями и именами групп, хранилище по-прежнему выдает сообщение об ошибке «Пользователю не разрешено входить в хранилище». Я предполагаю, что есть что-то еще, что мне нужно добавить в токен доступа или конечную точку userinfo список утверждений, чтобы приложение магазина могло принять пользователя, или какой-либо другой конфиг в консоли магазина или углерода?

1 Ответ

0 голосов
/ 30 января 2019

Причиной проблемы с входом пользователя в систему является то, что у пользователя нет соответствующих разрешений для входа в хранилище. Пользователю необходимо назначить ему внутреннюю / абонентскую роль. Поскольку пользователь приходит из OpenAM, а APIM не имеет никакой информации для его авторизации, произойдет сбой входа.

Для этого либо вы должны поделиться пользовательским хранилищем пользователей OpenAM с APIM (скажем, совместно используемым LDAP) и назначить пользователей с внутренней / абонентской ролью, либо использовать пользовательский код, чтобы добавить пользователя в хранилище пользователей APIM и назначить роль.

Другой простой способ - создать пользователя на стороне APIM (добавить фиктивный пароль) с ролью подписчика. но это не подходящее решение, если вы не знаете всех пользователей

...