У нас есть экземпляр IdentityServer3, который работает как отдельное приложение MVC. У нас есть несколько MVC веб-приложений, которые предоставляют различные услуги для нашей организации, и все они используют сервер IS3 для аутентификации и авторизации - все это работает без каких-либо проблем с SSO, работающей между всеми сайтами без проблем.
Теперь мне нужно начать разработку API-сервиса, который будет открыт для внешнего мира. Я пытаюсь реализовать этот API в одном из существующих MVC приложений - назовем его JT. Я успешно реализовал соответствующие изменения, добавив область видимости ресурса, изменив мой поток на гибридный и т. Д. c. Все работает отлично, и если у меня уже есть сеанс, я могу нормально вызывать API. Если у меня нет сессии, я перенаправляюсь на страницу входа в IS3. Все хорошо, верно?
У меня есть три основных вопроса:
Q1: Первый связан с тем, как наилучшим образом представить это стороннему потребителю TP C. Должен ли я создать вызов API под названием (например) «Проверка», который принимает комбинацию имени пользователя и пароля, которые являются учетными записями пользователей в системе JT, после проверки предоставит им маркер доступа, который они используют для последующих вызовов, что позволяет мне деактивировать их доступ, деактивировав эту учетную запись пользователя
-OR-
Создаю ли я определение клиента для каждого возможного поставщика, который может вызывать мой API с областью действия, ссылающейся только на мою область API? Позволить поставщику получить токен через вызов API для IS3 / токена, используя его clientId и secret? Таким образом, я деактивирую их доступ, забирая права на этот ClientID или полностью удаляя его. Наконец, если предположить, что это второй случай, то есть какая-то польза в том, чтобы не выставлять конечную точку IS3 / токена напрямую поставщику и вместо этого иметь их go с помощью моего метода validate, который вместо первого случая, Взаимодействует ли IS3 / token и передает ли токен вендору? Кто-нибудь делает это когда-нибудь?
Q2: Второй вопрос: я не вижу в IS3 нигде t ie определенной c области ресурсов для указанного c контроллера? Т.е., если бы у меня было более одного функционального API, для простоты предположим, что они находятся в ControllerA и ControllerB, я хочу предоставить доступ к ControllerA поставщику 1, но не разрешить поставщику 1 доступ к API, определенному в ControllerB. Как я могу сказать, что область «A-API» относится только к ControllerA или даже к указанным c методам в ControllerA? Любая документация или примеры, которые я могу найти, показывают простое использование [Authorize] для метода на этом APIController, но нет специфики связывания с какой областью, с которой он связан. Я действительно не хочу развертывать несколько приложений API, где каждому назначается только одна область ...
Q3: РЕДАКТИРОВАТЬ: Я считаю Я сам ответил на третий вопрос, изучив пользовательскую реализацию IClientStore, которая будет использовать нашу инфраструктуру среднего уровня для go в и из БД. Я оставляю оригинальный вопрос здесь для преемственности: наконец, в настоящее время у меня есть все области / роли / клиенты, загружаемые из моей БД при запуске. Есть ли документация, на которую кто-то может указать мне для обновления клиентов / областей / ролей во время выполнения без перезапуска IS3? В настоящее время все делается во время запуска IS3 и / или JT. Что делать, если я хочу добавить / удалить клиента / роль / et c. и эти настройки применяются динамически? Это поддерживается?
Спасибо! И еще раз прошу прощения, если это st00pid вопросы ...