перенаправить на другую проблему URL в ASP.Net

У меня есть два веб-приложения, и иногда мне нужно, чтобы пользователь переходил из одного приложения в другое. Поскольку это два веб-приложения, которые могут находиться в разных доменах/машинах, я не могу разделить сеанс между ними.

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

Мое текущее решение — генерировать все строки URL-адресов в обоих приложениях и добавлять к ним идентификатор пользователя после успешного входа пользователя в систему, например http://www.anotherapplication.com/somepage?userID=someuserID, значение userID извлекается из сеанса. Но я думаю, что мое решение глупо, и я хочу найти способ автоматически добавлять строку запроса ?userID=someuserID, когда пользователь переходит на другой URL-адрес в другом приложении, поэтому мне просто нужно создать общий унифицированный URL-адрес http://www.anotherapplication.com/somepage в обоих приложениях.

Есть ли решение для автоматического добавления строки запроса userID?

заранее спасибо, Джордж


asp.net redirect
person George2    schedule 15.02.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

Особенно рекомендую прочитать отличную статью Михаила Морозова. на тему SSO (Single sign ons).

person Cerebrus    schedule 15.02.2009
comment
Глупый вопрос после прочтения: информация о сеансе передается/доступна между разными веб-приложениями в разных виртуальных каталогах одного и того же веб-сайта IIS? Или совместно использовать разные веб-приложения на разных веб-сайтах IIS (может быть на разных компьютерах)? Или зависит от конфигурации in-proc/out-proc/SQL? - person George2; 15.02.2009
comment
Это должно быть Out of proc ... Если это разные машины, то это должно быть основано на SQL. - person Cerebrus; 15.02.2009
comment
1. Вы имеете в виду, что внутрипроцессный сеанс может использоваться только одним и тем же веб-приложением в одном и том же виртуальном каталоге? 2. И внепроцессный сеанс может быть разделен между разными веб-приложениями на одном компьютере, даже на разных веб-сайтах IIS? - person George2; 15.02.2009

arrow_upward
2
arrow_downward

Я не думаю, что это хорошая идея иметь идентификатор пользователя в строке запроса.

Лучшей идеей было бы реализовать решение с единым входом. В вашем сценарии вы можете сделать следующее:

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

Конечно, это выглядит как «много» перенаправления, но оно должно быть надежным, и это происходит только один раз, после чего ваш пользователь будет аутентифицирован в обоих приложениях.

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

  • Оба приложения должны знать общий ключ.
  • Первое приложение отправляет во второе приложение некоторые случайные данные («вызов»).
  • Второе приложение включает в свой ответ хеш-значение случайных данных + ответ + секретный ключ.
  • Теперь первое приложение может проверить, знает ли второе приложение секретный ключ, вычислив то же хеш-значение.

Взгляните на: http://en.wikipedia.org/wiki/Challenge-response_authentication

ИЗМЕНИТЬ:

Что касается состояния сеанса, см. http://msdn.microsoft.com/en-us/library/ms178581.aspx для обзора. Можно разделить состояние сеанса между приложениями, но в целом я бы не рекомендовал это делать. Если ваше приложение находится в разных доменах (URL), вам придется использовать состояние сеанса без файлов cookie; что не безопасно. Если вы решите пойти по этому пути, вам придется либо использовать сервер состояний, либо SQL Server для сохранения сеанса, в зависимости от вашей настройки.

person driis    schedule 15.02.2009
comment
Привет, driis, твоя идея классная! У меня есть одна проблема: передача токена аутентификации в строке запроса небезопасна? У меня есть этот вариант, потому что я чувствую, что что-то (URL + строка запроса), видимое в IE, более склонно к раскрытию и небезопасно? Любые комментарии? - person George2; 15.02.2009
comment
В целом да, передача токена аутентификации в строке запроса считается небезопасной. Но, используя подход «вызов-ответ», как я описываю, его можно сделать безопасным. Часть запроса-ответа гарантирует, что вы можете быть уверены, что токен аутентификации исходит от вашего приложения и является действительным. - person driis; 15.02.2009
comment
Я снова прочитал ваше четырехэтапное решение и столкнулся с проблемой: ваше решение аутентифицирует приложение друг против друга, но для реализации единого входа я хочу аутентифицировать пользователя в приложении. Ваше решение связано с моим вопросом? - person George2; 15.02.2009
comment
убедитесь, что токен аутентификации исходит от вашего приложения и является действительным. -- Я согласен, но разве раскрытие аутентификационной информации в строке запроса небезопасно? Предположим, что другие могли бы прослушивать или взламывать людей, которые могли бы поделиться строкой запроса с другими, чтобы сэкономить на покупке членства? :-) - person George2; 15.02.2009
comment
Решение будет зависеть от того, аутентифицирует ли себя пользователь как обычно в любом из приложений. Затем, когда он обращается к другому приложению, вы можете использовать описанное решение, чтобы проверить, аутентифицирован ли текущий пользователь в первом приложении. - person driis; 15.02.2009
comment
Что касается вашего комментария о раскрытии информации для аутентификации - нет, вы бы не раскрывали информацию для аутентификации, как в пароле, если вы это имеете в виду. Общий общий ключ гарантирует, что токен проверки подлинности может быть сгенерирован только тем, кто знает ключ. - person driis; 15.02.2009
comment
... и повторная атака невозможна, поскольку вы начинаете с другой задачи (случайные данные) для каждой попытки аутентификации. - person driis; 15.02.2009
comment
Но токен аутентификации генерируется секретным ключом, раскрытие токена аутентификации означает раскрытие информации о секрете, и он / она, представляя токен аутентификации, может притвориться, что знает секретный ключ, не так ли? :-) - person George2; 15.02.2009
comment
Прохладный! вы начинаете с другой задачи (случайные данные) для каждой попытки аутентификации - вы предлагаете передавать токен аутентификации в форме SSL? Меня беспокоит использование этого токена несколькими людьми более одного раза. как избежать? - person George2; 15.02.2009
comment
Важно помнить, что вы предоставляете только хэш-значение, сгенерированное на основе секретного ключа, поэтому вы не раскрываете информацию о секретном ключе. Хеш-функция необратима и является одним из краеугольных камней криптографии. en.wikipedia.org/wiki/Hash_function - person driis; 15.02.2009
comment
Передача строки запроса в порядке. Но мой вопрос в том, как я могу добавить строку запроса до того, как пользователь перейдет на другой сайт. Предположим, моя страница содержит URL-адрес другого приложения, URL-адрес не контролируется текущим приложением, и пользователь сразу же переходит к целевому приложению. - person George2; 15.02.2009
comment
Итак, в этой ситуации, как я могу добавить строку запроса непосредственно перед переходом к другому приложению? Я не могу предсказать, когда пользователь прыгнет. Любые идеи или решения? :-) - person George2; 15.02.2009

arrow_upward
0
arrow_downward

Вы можете сохранить сеанс, используя что-то еще, кроме InProc (сокращение от in process). Если вы сохраните сеанс с помощью бэкэнда SQL Server, вы сможете восстановить сеанс между доменами/компьютерами, если они настроены на использование одного и того же бэкэнда SQL Server для хранения сеансов. Это настраивается в ASP.NET и поддерживается по умолчанию. Я предлагаю вам посмотреть его.

person John Leidegren    schedule 15.02.2009
comment
Хотя это верно, если доступ к приложениям осуществляется в другом домене; другое приложение не может получить доступ к файлу cookie идентификатора сеанса. Asp .NET поддерживает сохранение идентификатора сеанса в строке запроса, но в зависимости от сценария это может быть невозможно. - person driis; 15.02.2009
comment
Немного смущен, так как раньше я не использовал SQL Server для хранения статуса сеанса. Не знаете, как обмениваться информацией о сеансе между приложениями в разных доменах? то есть при переходе к другому приложению, как целевое приложение может распознать, что вы Джордж, а не Джон? Вы должны передать некоторую информацию, когда прыгаете? - person George2; 15.02.2009
comment
Спасибо, driis, Asp .NET поддерживает сохранение идентификатора сеанса в строке запроса, но в зависимости от сценария это может быть невозможно - у вас есть образец для этого? - person George2; 15.02.2009
comment
Джон, что ты имеешь в виду, когда сказал куки настроить таргетинг на другой домен? Доступ к cookie с другого домена невозможен. :-) - person George2; 15.02.2009