ASP.NET "вход в систему" с внешнего сайта - PullRequest
2 голосов
/ 10 августа 2009

Посмотрел, но не могу найти ответ. Не знаю точно, каким должен быть заголовок. Надеемся на некоторые предложения из «нестандартного». Я не думаю, что могу быть единственным, кто сталкивается с этим.

«Как приложение ASP.NET лучше всего« принять », что авторизация пользователя уже выполнена на веб-сайте»?

У нас есть собственное приложение ASP.NET (2.0). Он поддерживает проверку подлинности FBA или Windows, а также имеет собственную таблицу «имя пользователя + пароль» для входа в систему не из Windows. Теперь клиенты спрашивают нас - которые обычно позволяют своим пользователям входить в систему через интранет + вход в Windows - как они могут «встроить» наше приложение в свой собственный веб-сайт и разрешить своим внешним внешним интернет-клиентам получать к нему доступ *. 1007 *

Требование заключается в том, что (внешний) клиент войдет в свою «область сайта участника» с некоторой аутентификацией по имени пользователя и паролю. Затем они хотят получить доступ к нашим страницам «прозрачно» - прежде всего, конечному пользователю не нужно повторно вводить имя пользователя и пароль, у нас должен быть какой-то способ просто «принять» переданное имя пользователя. У нас нет никакой возможности узнать, что сайт может иметь на пути их собственной аутентификации ; их собственный сайт может быть написан, скажем, на ASP, и они, вероятно, захотят приложить очень мало усилий, чтобы что-то изменить.

Итак, как мне подойти к этому? Я понимаю, что ничто не будет надежным; покупатель этого не ожидает, но ожидает некоторого минимума. Например, если я просто скажу им «встроить URL в наше приложение с именем? Username = ... on в вашем приложении», это будет означать, что любой посторонний знает, что может попасть в наше приложение без предварительной проверки их подлинности. Ввод пароля на URL вряд ли поможет ... Есть ли какой-нибудь совет, как это решить? Или просто «убедитесь, что доступ к веб-страницам в первую очередь защищен, чтобы пользователи не могли получить доступ к вашему приложению напрямую»?

Надеюсь, это не слишком долго. Я знаю, что это туманная область, любые предложения будут оценены.

Ответы [ 4 ]

1 голос
/ 10 августа 2009

Предостережение : Это, вероятно, само собой разумеется, но вы должны долго и усердно думать об этом. С параметрами, которые вы дали, вы рискуете открыть всю свою систему для любого, кто достаточно любопытен, чтобы начать возиться. Я не уверен, насколько чувствительна природа ваших данных, но все, что нужно, это одно нарушение и злой клиент, и вы можете быть в большом количестве горячей воды.

Если вы не собираетесь просить своих клиентов проделать большую работу с их стороны, ваши варианты будут довольно ограничены.

На очень дешевом конце спектра вы можете попросить их дать ссылку на страницу на вашем сайте, где они, возможно, передадут какой-то идентификатор siteId и имя пользователя в строке запроса, и тогда вы сможете по крайней мере убедиться, что ссылающаяся URL (www.yourcustomersite.com) совпадает с сайтом. Если бы вы держали его в своей таблице.

Недостатком этого является то, что рефереры могут быть подделаны, так что это не будет очень надежным решением, но лучше, чем ничего.

Если бы вы могли заставить своих клиентов выполнять небольшую работу, вы могли бы по крайней мере предоставить уникальный маркер аутентификации для каждого пользователя со своей стороны и потребовать, чтобы они отправили вам токен вместо имени пользователя. Таким образом, вместо имени пользователя вы можете получить? SiteId = yourCustomer & authToken = DKDlas29df9aa01sk.

Опять же, это не намного лучше, но, по крайней мере, делает атаку грубой силой чуть сильнее, хотя и не намного.

Надеюсь, это поможет. Удачи!

1 голос
/ 10 августа 2009

Вы думали о билетах? Будут ли они заинтересованы во внедрении веб-службы, чтобы оформить билет для пользователя, который входит в их веб-приложение. Затем, когда пользователь посещает ваше веб-приложение, вы можете проверить его билет (фактически проверить его с помощью веб-службы) ... возникает небольшая проблема с тем, как браузер клиента сохраняет билет ...

С другой стороны, я вижу логи stackoverflow у пользователей, использующих OpenID ... (пользователям нужно будет ввести свои учетные данные дважды, но они будут использовать одну и ту же учетную запись), будет ли этого достаточно для них?

0 голосов
/ 10 августа 2009

, пожалуйста, отметьте это сообщение в блоге * во-первых, 1002 *, это подробное руководство по единому входу в веб-приложениях ASP.net.

Теперь, что касается решения, представленного там для сайтов в разных доменах (вы не можете использовать cookie-файл для аутентификации, если вы находитесь в совершенно другом домене), я думаю, что у него есть серьезные проблемы с безопасностью. Мы сделали что-то похожее на предложение Андрея на сайте с SSO. Когда пользователь входит на основной сайт и затем хочет посетить дополнительный сайт, ссылка на сайт содержит тикет (мы использовали случайный Guid). Основной сайт хранит в базе данных информацию о сеансе, связанную с Guid и временем создания (для истечения срока действия билета). Когда вторичный сайт обнаруживает нового неаутентифицированного пользователя и билет, с которым он связывается с главным сайтом через веб-службу, вторичный сайт проверяет билет и возвращает всю информацию сеанса, которую он сохранил. Затем другой сайт может аутентифицировать пользователя и выдать свой собственный куки-файл аутентификации. Вам нужно будет что-то реализовать, чтобы поддерживать основной сеанс сайта, пока пользователь просматривает другой сайт, поэтому ему не нужно будет входить в систему, если он отсутствует некоторое время. Это может быть достигнуто с помощью постоянного файла cookie или с помощью iframe на дополнительном сайте, указывающего на фиктивную страницу на основном сайте.

0 голосов
/ 10 августа 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...