Вопрос

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

Пользователь регистрируется на веб-сайте 1, а затем переходит на веб-сайт 2.Как сайт2 узнает, что пользователь вошел в систему?Я предполагаю, передав некоторый токен в URL-адресе, который будет проверен веб-сайтом 2 в базе данных на достоверность.Это означает, что мне нужно упорядочить все URL-адреса на веб-сайте 1, которые ведут на веб-сайт 2?

Во-вторых, если пользователь продолжает просматривать веб-сайт 2, скажем, 1 час, а затем переходит на веб-сайт 1.К тому времени время сеанса веб-сайта1 истекло, и пользователь увидит страницу входа, не так ли?Но такое поведение неверно с точки зрения единого знака функциональности.

Это было полезно?

Решение

Я думаю, вы неправильно понимаете, как работает единый вход.

Давайте рассмотрим website1 и website2, которые хотят использовать единый вход.

Сайт входа в систему создается на identityProvider. Это единственное место, где появляется экран входа в систему.

Когда пользователь заходит на веб-сайт1 и выбирает войти в систему, веб-сайт1 отправляет пользователя на экран входа в систему identityProvider. Пользователь регистрируется на identityProvider, который сбрасывает свой собственный файл cookie для входа в свой домен (и, возможно, позволяет пользователю сохранять свои данные аутентификации, чтобы их больше никогда не запрашивали). Затем он перенаправляет браузер обратно на website1, включая токен в запросе, который взламывает website1, получает идентификационную информацию и выполняет собственные биты входа в систему (отбрасывая свой собственный куки-файл аутентификации, который длится так, как ему нужно).

Затем пользователь заходит на сайт2 и выбирает вход в систему. Website2 привязывает пользователя к identityProvider, который уже знает, кто пользователь, и, если пользователь выбрал сохранение своей регистрационной информации, автоматически выполняет аутентификацию и затем перенаправляет обратно на website2 с другим токеном, который website2 взламывает, а затем выполняет свои собственные биты входа.

Вокруг этого существует множество мер безопасности, ограничивающих токены определенными веб-сайтами, позволяя отправлять только токены на веб-сайты из белого списка и т. д. и т. д.

Итак, чтобы решить ваши проблемы

<Ол>
  • Пользователь заходит на сайт website1, а затем переходит на сайт website2. Как website2 узнает, что пользователь вошел в систему? Это не так. website2 сначала должен запросить информацию для аутентификации на сайте единого входа.
  • Это означает, что мне нужно собрать все URL-адреса в website1, которые переходят на website2? Нет, если только вы не сделаете website1 провайдером идентификации. Даже тогда это было бы больно, лучше, если website2 перенаправляет обратно к поставщику удостоверений, если токен необходим.
  • Во-вторых, если пользователь продолжит просматривать сайт2, скажем, 1 час, а затем перейдет на сайт1. К тому времени сеанс website1 истек, и пользователь увидит страницу входа, не так ли? - Это зависит от того, как вы настраиваете website1 и как долго длится файл cookie для аутентификации.
  • Но это поведение неправильно из-за единого входа в функциональность. Нет, это не так. Единая регистрация не означает, что вы получаете плавающий токен, который распределяется между сайтами. Каждый веб-сайт, который использует единый вход, по-прежнему создает свой собственный файл cookie для аутентификации. Что может произойти, если пользователь вернется на веб-сайт1, он обнаружит просроченный файл cookie для аутентификации, а затем снова отправит пользователя на страницу единого входа, где он будет аутентифицирован (без вывода сообщений), и новый токен будет возвращен на веб-сайт1, который создаст новый cookie для аутентификации для себя.
  • Другие советы

    Официальный подход Microsoft заключается в использовании служб федерации Active Directory (в которых SAML используется для аутентификации AD). Это имеет характеристики, которые вы ищете, но, возможно, слишком тяжелый для общедоступного веб-приложения.

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

    Оба приложения используют один и тот же открытый ключ шифрования для кодирования / декодирования токена безопасности. Как вы говорите, это работает нормально, если у вас есть ограниченные, предварительно определенные переходные ссылки между сайтами, но если вы хотите иметь возможность использовать любые ссылки на страницы между приложениями, вам нужно будет генерировать эти URL-адреса на лету, чтобы они содержали токен.

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

    Обычно маркер безопасности содержит идентификатор пользователя и тайм-аут, а средство проверки входа в систему возвращает идентификатор пользователя или ноль, если тайм-аут истек.

    Это не быстрое решение для правильного и безопасного кодирования. Может быть, вы можете найти готовый на Code Project?

    Вы можете использовать другой механизм единого входа для разных приложений в зависимости от вашего приложения.

    Однако я мог видеть»Готовый единый вход» сервис от Live, Google, Yahoo, Facebook и т. д.для обеспечения аутентификации путем поддержки SAML.Это поможет нам избавиться от проблем с поддержкой реализации нашей собственной службы единого входа.

    Если вам нужно базовое понимание того, как работает SSO, вы можете обратиться здесь

    MS несколько лет назад написала об этом на предприятии - мы создали образцы, но так и не реализовали их по-настоящему - Единый вход

    Проверьте эту ссылку с помощью OAuth и социальных провайдеров, она предлагает множество возможностей аутентификации, уже встроенных в .Net Обучающее видео Microsoft по OAuth и единому входу с социальными провайдерами

    scroll top