#c# #asp.net-mvc-4 #single-sign-on #wif
#c# #asp.net-mvc-4 #единый вход #с помощью
Вопрос:
Я читаю о едином входе и использовал этот учебник http://chris.59north.com/post/2013/04/09/Building-a-simple-custom-STS-using-VS2012-ASPNET-MVC.aspx для создания пользовательского STS.
Если я правильно понял, на компьютере STS установлен сертификат. Повторная сторона отправляет отпечаток подписи x509. Таким образом, проверяющая сторона будет принимать только заявки STS с соответствующим сертификатом. Правильно ли это?
Если это так, я хотел бы реализовать, чтобы каждая проверяющая сторона отправляла сертификат в STS, который также был установлен STS. По запросу STS просматривает в своем списке доверенных проверяющих сторон, известен ли отправленный сертификат STS.
Является ли эта реализация хорошей идеей и является ли это хорошей практикой? Есть ли хороший ресурс для реализации этого?
Спасибо
Ответ №1:
внедрение пользовательского STS — тяжелая работа. Я бы посоветовал вам взглянуть на Windows azure ACS или Thinktecture free STS в качестве отправной точки.
При этом наличие отдельного сертификата для проверяющей стороны является обычной практикой. Однако закрытый ключ этого сертификата обычно хранится в некоторой базе данных в STS (ACS и Thinktecture поддерживают это). Проверяющая сторона знает только открытый ключ. Затем acs подписывает токен безопасности (SAML2 или JWT) с помощью токена безопасности, и проверяющая сторона может использовать открытый ключ (или отпечаток пальца) для проверки подписи. Пожалуйста, также обратите внимание, что токен SAML2 также может быть зашифрован (рядом с подписью) и что для этого вы можете использовать другой сертификат. Я лично рекомендовал бы использовать отдельный сертификат, если у STS (или вашей организации) есть какой-то веб-сайт, где «кто угодно» может зарегистрировать свое приложение в качестве проверяющей стороны. Если все ваши сторонние стороны являются «внутренними» приложениями, я бы, по крайней мере, рассмотрел возможность использования единого сертификата для подписи всех токенов безопасности. Преимущество этого заключается в том, что вы можете опубликовать (открытый) ключ в документе метаданных Федерации (расположенном по адресу FederationMetadata/2007-06/FederationMetadata.xml ). Если вы хотите обновить ключ, вы можете обновить его там (сначала опубликовав там новый и старый ключ, а затем только новый ключ). Затем проверяющие стороны могут обновлять там ключи на основе этих метаданных (adfs использует аналогичный подход). Итак, итог: наличие отдельного сертификата для каждого RP хорошо, но наличие одного (для подписи, а не для шифрования) намного проще обновить.