Является ли использование токенов-носителей SAML для аутентификации пользователей в серверных службах плохой идеей?

Предположим, у меня есть фронтальное -приложение, которое хочет получить некоторые данные из серверной -конечной службы. (Да. )Служба должна будет удостовериться, что конечный -пользователь аутентифицирован, что он уполномочен использовать службу и, возможно, отфильтровать возвращенные данные на основе привилегий пользователя. В моем случае,как клиентское -конечное приложение, так и серверная -конечная служба используют Azure ACS для проверки подлинности.

Simple federated identity scenario

В идеале передняя часть -хотела бы действовать от имени аутентифицированного пользователя, что хорошо подходит для использования токена ActAs(, как указано в WS -Trust ). Однако оказывается, что ACS в настоящее время не поддерживает ActAs .

Обходной путь может состоять в том, чтобы использовать фактический токен носителя (. токен начальной загрузки в переднем -конечном приложении )для аутентификации в задней -конечной службе. Это несложно сделать , но не будет ли это по какой-то причине плохой идеей?

5
задан Community 23 May 2017 в 12:19
поделиться