Безопасное создание маркера SAML2 в клиентском приложении без сертификата подписи установки

Question

У меня есть клиентское приложение (окна), в которое пользователь входит. Из этого приложения пользователь захочет получить доступ к удаленному веб-сайту с помощью единого входа (SAML) и будет аутентифицироваться Microsoft WIF. Для этого пользователь нажмет кнопку, которая открывает локальный веб-браузер, генерирует токен SAML (содержащий имя пользователя и роли и т. Д.) И делает HTTP POST на удаленном веб-сайте для доступа к нему, подписывая их.

Я хочу, чтобы пользователь был подписан в автоматическом режиме на основе своих учетных данных из приложения Windows.

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

Установка этого сертификата выглядит не совсем правильно. Как еще я могу безопасно разрешить пользователям создавать токен SAML, который будет принят Поставщиком услуг (через единый вход)?

UPDATE:

Пользователь не прошел проверку подлинности в приложении Windows с помощью проверки подлинности Windows (Kerberos), мы делаем заказ SQL вызов к базе данных имя пользователя/пароль.

В выигрышном приложении мы будем знать имя пользователя и их роли, поэтому можем генерировать утверждения из этого или передать его удаленной STS для генерации и подписи маркера SAML. Но снова передача этих данных в STS кажется совершенно неправильной снова.

Answer 1

Сертификат подписи не должен находиться на рабочем столе пользователя. В противном случае любой пользователь может потенциально генерировать токен SAML с желаемым пользователем.

Что вы хотите - это Служба безопасного токена (STS): поставщик удостоверений, который будет проверять подлинность вашего пользователя через Kerberos (так как вы хотите повторно использовать личность вошедшего в систему пользователя) и предоставить подписанный токен SAML ,

Все это можно сделать при открытии веб-представления в приложении. Стартовый URL-адрес должен быть конечной точкой Provider Identity для инициированного IDP SSO с параметром url, определяющим службу, к которой вы хотите получить доступ.