как реализовать единую точку входа в .NET?
Не в RFC , нет, но существуют практические пределы.
протокол HTTP не устанавливает априорной границы длины URI. Серверы ДОЛЖНЫ быть в состоянии обработать URI любого ресурса, которому они служат и ДОЛЖНЫ быть в состоянии обработать URIs неограниченной длины, если они обеспечивают, ДОБИРАЮТСЯ - базирующиеся формы, которые могли бы генерировать такой URIs. Сервер ДОЛЖЕН возвратить 414 состояний (Request-URI Too Long), если URI более длинен, чем сервер может обработать (см. раздел 10.4.15).
Примечание: Серверы должны быть осторожны относительно в зависимости от длин URI выше 255 байтов, потому что некоторый клиент старшего возраста или реализации прокси не могут правильно поддерживать эти длины.
4 ответа
Я думаю, вы неправильно понимаете, как работает единый вход.
Давайте рассмотрим веб-сайты 1 и 2, которые хотят использовать единый вход.
Веб-сайт входа в систему создается в identityProvider. Это единственное место, где появляется экран входа в систему.
Когда пользователь посещает веб-сайт 1 и выбирает вход, веб-сайт 1 отправляет пользователя на экран входа в систему на identityProvider. Пользователь входит в identityProvider, который удаляет свой собственный файл cookie для входа в свой домен (и, возможно, позволяет пользователю сохранять свою информацию для аутентификации, чтобы он больше никогда не запрашивался). Затем он перенаправляет браузер обратно на веб-сайт 1, включая токен в запросе, который веб-сайт 1 взламывает, получает идентификационную информацию и выполняет свои собственные биты входа (удаляя свой собственный файл cookie аутентификации, который действует так, как он хочет).
Затем пользователь заходит на сайт2 и выбирает вход. Website2 перенаправляет пользователя на identityProvider, который уже знает, кем является пользователь, и, если этот пользователь решил сохранить свою информацию для входа, молча аутентифицируется, а затем перенаправляется обратно на сайт2 с другим токеном, который сайт2 взламывает, а затем выполняет свои собственные биты входа.
Вокруг этого есть множество мер безопасности, ограничивающих токены определенными веб-сайтами, разрешая отправку токенов только на веб-сайты из белого списка и т. Д.
Итак, чтобы решить вашу проблему
- Пользователь регистрируется на сайте1, а затем переходит на сайт2. Как website2 узнает, что пользователь вошел в систему? Это не так. website2 должен сначала запросить информацию для аутентификации с сайта единой регистрации.
- Это означает, что мне нужно упорядочить все URL-адреса в website1, которые ведут на website2? Нет если только вы не сделаете website1 поставщиком удостоверений. Даже в этом случае это будет болезненно, лучше, если веб-сайт2 перенаправляет обратно поставщику удостоверений, если требуется токен.
- Во-вторых, если пользователь продолжает просматривать веб-сайт 2 в течение, скажем, 1 часа, а затем переходит на веб-сайт1. К тому времени время сеанса website1 истекло, так что пользователь увидит страницу входа в систему, не так ли? - Это зависит от того, как вы настраиваете website1 и как долго хранятся файлы cookie аутентификации.
- Но такое поведение неверно с точки зрения функции единого входа. Нет, это не так. Единый вход не означает, что вы получаете плавающий токен, который используется совместно сайтами. Каждый веб-сайт, использующий систему единого входа, по-прежнему создает собственный файл cookie для аутентификации. Что может произойти, если пользователь вернется на сайт1, он обнаружит просроченный файл cookie аутентификации, затем снова отправляет пользователя на страницу единого входа, где он аутентифицируется (без уведомления), и новый токен возвращается на сайт 1, который создает для себя новый файл cookie аутентификации.
Официальный подход Microsoft - через службы федерации Active Directory (которые объединяют SAML с аутентификацией AD). У него есть характеристики, которые вы ищете, но, возможно, он слишком тяжелый для общедоступного веб-приложения.
Несколько лет назад MS подготовила документ об этом в рамках предприятия - мы настроили образцы, но так и не реализовали его на практике - Единый вход
Я предполагаю, что вы не хотите использовать проверку подлинности Windows с Active Directory и т. д. Один из способов - для передачи от одного аутентифицированного сеанса к другому с использованием токена безопасности в строке запроса, как вы описываете.
Оба приложения используют один и тот же открытый ключ шифрования для кодирования / декодирования токена безопасности. Как вы говорите, это отлично работает, если у вас есть ограниченные предопределенные ссылки перехода между сайтами, но если вы хотите иметь возможность использовать любые ссылки на страницы между приложениями, вам нужно будет генерировать эти URL-адреса на лету, чтобы они содержали токен.
Способ обработки тайм-аутов заключается в том, что токен безопасности также содержит время истечения срока действия. Вы создаете новый токен безопасности при каждом запросе страницы или при создании новой ссылки между приложениями.
Обычно маркер безопасности содержит идентификатор пользователя и тайм-аут, а средство проверки входа в систему либо возвращает идентификатор пользователя, либо ноль, если время ожидания истекло.
Это не быстрое решение для правильного и безопасного кодирования. Может, вы найдете готовый вариант в Code Project?