pre-authenticate user in aspx application

Question

У нас есть 2 приложения, одно в Nodejs, а другое в aspx.
Страница входа в Nodejs. Мне нужно создать сеанс и аутентифицировать моего пользователя в приложении aspx со страницы входа для последующей навигации в приложении aspx.

Будучи noob в веб-разработке, я понятия не имею, с чего начать или что искать.

Заранее спасибо

Answer 1

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

1) Возможно, самый простой вариант, если вы можете сделать это, чтобы процесс Node.js был шлюзом. Приложение ASP.NET никогда не нуждается в аутентификации пользователей вообще, приложение Node.js действует как полный обратный прокси-сервер для приложения ASP.NET. Это хорошо работает, если вы можете его поддерживать, и вы можете защитить его, указав приложение приложения Node.js в приложении ASP.Net (используя любой метод, который вы хотите, базовый auth, login форм и т. Д.). Если вам нужно, чтобы приложение ASP.Net было известно о том, что пользователь находится в текущем контексте, вы можете указать любую информацию, которая вам нужна, в заголовки запроса, чтобы сделать это (например, если у них есть одна и та же база данных, вы coudl помещаете в Id пользователя, которому установлено приложение узла). Если вы хотите, чтобы приложение ASP.NET было доступно как самостоятельно, так и через приложение-узел, приложение-узел становится одним из многих пользователей, а для приложения asp.net требуется HTTP-модуль для нормализации того, поступает ли информация пользователя из Сессия или из заголовков Http. Самый простой способ сделать это - проверить, что Http-модуль проверяет, что текущий пользователь имеет заданную роль (например, NodeApp) и входит в систему, а затем он либо копирует информацию пользователя из HttpContext в новую переменную сеанса (что остальная часть приложения использует), или же ищет прокси-пользователя в БД и делает то же самое. В основном, остальная часть приложения никогда не будет доверять текущему пользователю HttpContext для принятия решений в этот момент.

Pro: достаточно простая архитектура, не зависит от того, в какой области находится каждое приложение. Оба приложения нуждаются в доступе к пользовательской базе данных, чтобы он работал хорошо.

Con: Если по какой-то причине приложения не могут иметь доступ к одному пользователю db, это не так хорошо. Есть некоторые накладные расходы для выполнения прокси (не так много, но все же там). Немного мозг гибнет вокруг, говоришь ли вы о «реальном» пользователе или «узле», который вам нужно держать прямо.

2) OAuth (или, альтернативно, OpenID) является самым стандартным вариантом. В этом случае вы должны установить приложение Node.js в качестве поставщика OAuth и иметь приложение ASP.NET как потребитель OAuth. Затем пользователь может использовать свое имя пользователя и пароль для входа в систему, а приложение Node передает токен аутентификации в приложение ASP.NET через существующие модули аутентификации.

Pro: Меньше кода для написания на стороне ASP.NET, чем приведенный выше пример, совместимый со стандартами. вы можете отключить (или добавить) поставщиков OAuth, если хотите позже

Con: Немного больше косвенности для пользователя (перенаправляет между приложениями). Вероятно, это можно свести к минимуму, но вам нужно хорошо ознакомиться с протоколами OAuth.

3) Совместное использование сеанса (считается захватом сеанса, если кто-то делает это с вами). Если вы находитесь в том же домене, приложение Node.js может просто выписать сеанс ASP.NET, а файлы cookie, такие как ASP.NET, будут. Я говорю «просто», но есть много деталей механизма ASP.NET, которые вам нужно будет понять, чтобы сделать это правильно. http://support.microsoft.com/kb/910443.Основными битами являются то, что вам нужно будет разместить хранилище сеансов ASP.NET в базе данных, а затем Node.js будет управлять добавлением и удалением элементов оттуда, чтобы когда ASP.NET просматривал сеанс & auth cookies по заданному запросу он может найти их в том месте, которое он ожидает найти, а затем процесс ASP.NET найдет их там и будет действовать соответствующим образом.

Pro's: Использует машину ASP.NEt, которая уже на месте до некоторой степени Con: Наверное, довольно хрупкая, все рассмотрено. Вашему приложению node.js потребуется доступ к machineKey, который приложение ASP.NEt будет использовать для расшифровки содержимого сеанса. Вам нужно убедиться, что вы используете один и тот же алгоритм шифрования, и оба приложения будут связаны с одним и тем же хранилищем сеансов.

4) Внесите свой собственный членский член в ASP.NET, чтобы выдать билет Forms Auth в приложение Node. Это несколько похоже на смесь 1 и 3. В этом случае приложение Node после аутентификации пользователя отправляет другой запрос конечной точке входа на сервере ASP.Net, предоставляя ему учетные данные, идентифицирующие себя, как вы хотите (например, общий ключ, который каким-то образом был зашифрован). Он также может предоставить любые пользовательские данные, которые вы хотите. Затем вы можете вручную вызвать Api-аутентификацию форм api в своем коде ASP.NET, чтобы создать билет для конечного пользователя (http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket.aspx), т. Е. Не вычислять его самостоятельно; сеансовый магазин может быть где угодно. Ответ на приложение Node.js будет включать данные о билетах в файл cookie auth, поэтому ваше приложение Node.js может передать эти данные вашему пользователю, так что в следующий раз, когда они сделают запрос к приложению ASP.nEt, они У меня будет действительный файл cookie, созданный asp.net.

Pro's: более гибкий, чем # 3 и менее пользовательский mungery, чем # 1 с точки зрения ASP.NET. Con: По-прежнему требуется, чтобы оба приложения в одном домене все еще нуждались в большой интеграции между ними. Если вы испортите свой членский провайдер, вы можете случайно создать дыру в своей безопасности.

В целом, я думаю, что решение OAuth является лучшим, но это все методы, которые я могу придумать для этого.