Как отправить идентификатор пользователя между различными приложениями в ASP.Net?

Question

У меня есть два веб-приложения, и оба они разработаны в ASP.NET. Теперь я хочу предоставить функцию, позволяющую пользователю переходить с одного URL-адреса на сайте приложения (один виртуальный каталог IIS) A на другой URL-адрес на сайте приложения B (другой виртуальный каталог IIS).

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

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

Решение 2: Когда пользователь перенаправляет на URL-адрес на другом сайте, я могу добавить идентификатор пользователя после URL-адреса, я могу перенаправить на этот URL-адрес на другом сайте http://www.anotherapplicationsite.com/somesuburl?userID=foo,, но я странно, что таким образом userID будет легко разоблачить, что поднимает вопросы безопасности.

Answer 1

Я много работаю с такими вещами. То, что вы ищете, звучит как решение для единой регистрации или Federated Security.

Вы можете попробовать сделать что-то похожее на следующее:

1. Создать простую базу данных или другую таблицу хранения с двумя столбцами "nonce" и "username"

2. Когда вы создаете ссылку на другой сайт, создайте GUID или другой уникальный идентификатор для использования в качестве одноразового одноразового номера, передавая его в виде строки запроса? Id =. Вставьте запись в таблицу с текущим аутентифицированным именем пользователя и уникальным идентификатором, который вы создали.

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

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

Также полезно включить дату и время в таблицу nonce / username и истечь ее через 60 секунд или менее, чтобы минимизировать риск повторных атак. Мы также требуем, чтобы клиентские сертификаты для внешних приложений вызывали веб-сервис для проверки личности вызывающего абонента. Внутренние приложения не требуют использования клиентских сертификатов.

Приятно то, что он достаточно хорошо масштабируется на столько сайтов, сколько вы хотели бы использовать

Не идеальная защита, но у нас никогда не было существенного компромисса с такой системой.

Answer 2

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

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

D

Answer 3

используя междоменный домен, вы не можете РАЗДЕЛИТЬ сеанс, поэтому я думал о POST

идея 1

если боится «показывать» имя пользователя в адресе, почему бы не отправить POST?

<form name="myForm" action="http://www.mydomain.com/myLandingPage.aspx">
  <input type="hidden" id="userid" value="myUsername" />
  <a href="javascript:myForm.Submit();">click here</a>
</form>

но тогда ... конечно, "Просмотр исходного кода" покажет это

идея 2

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

 http://www.anotherapplicationsite.com/somesuburl?userID=HhN01vcEEtMmwdNFliM8QYg+Y89xzBOJJG+BH/ARC7g=

Вы можете использовать алгоритм Rijndael для этого, ссылка ниже имеет код VB и C #:

http://www.obviex.com/samples/EncryptionWithSalt.aspx

затем на сайте 2, просто расшифруйте и проверьте, существует ли пользователь ... если это так, продолжайте, если не говорите, что пользователь пытался умерить строку запроса:)

Answer 4

Пока у вас есть хорошая система аутентификации на втором веб-сайте, я думаю, что решение 2 - это то, что вам нужно, принимая во внимание замечание Эндрю о секретных идентификаторах, конечно.

Для получения дополнительной информации о шифровании: см. Документацию FormsAuthentication.Encrypt Method . Я думаю, что они даже делают что-то с записью значения в куки в этом примере.

Answer 5

Что вы используете в качестве идентификатора пользователя? Если вы используете их номер социального страхования или адрес электронной почты (что-то чувствительное), то вы захотите зашифровать значение, прежде чем поместить его в строку запроса. В противном случае (если идентификатор пользователя является чем-то неоднозначным, например, целое число или идентификатор GUID), можно поместить идентификатор в строку запроса.

Answer 6

Я не думаю, что 1) будет работать из-за безопасности браузера (куки с одного домена не могут быть прочитаны другим доменом). Я бы пошел с 2), за исключением того, что я бы зашифровал значение строки запроса.

РЕДАКТИРОВАТЬ: Подробнее о конфиденциальности и безопасности файлов cookie см. В разделе «Конфиденциальность и файлы cookie третьих сторон» здесь .