Можно ли защитить несколько отдельно размещенных API-интерфейсов за одним APIResource? - PullRequest
0 голосов
/ 15 февраля 2019

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

Мы используем IdentityServer 4 в качестве нашей реализации oauth.

Например,

У нас есть 2 службы, которые предоставляют данные расписания, которые находятся на 2 отдельных API, размещенных на двух отдельных URL-адресах, поскольку онииметь дело с различными сторонними системами.

Пользователь заинтересован только в предоставлении доступа к его данным расписания, поэтому я планировал использовать одну область действия (schedule.read) для двух APIResource, которые я с тех пор обнаружил:недопустимо в IdentityServer, см. https://github.com/IdentityServer/IdentityServer4/issues/2304.

Что-то не так с концептуальным моделированием их как одного APIResouce в IdentityServer, но с использованием двух дискретных API.Я не могу найти ничего, что могло бы предотвратить это в IdentityServer.

1 Ответ

0 голосов
/ 15 февраля 2019

Нет ничего плохого в том, что вы делаете.Если ваши несколько отдельно размещенных API-интерфейсов на самом деле являются частью одного виртуального API-интерфейса в пределах вашей проблемной области бизнеса, то физическое разделение не имеет значения, и, как вы уже рассмотрели, в реализации Identity Server 4 нет ничего, что могло бы предотвратить это.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...