Лучшие практики аутентификации (входа в систему) ASP.Net MVC 2

Question

Я разрабатываю приложение ASP.Net MVC 2 в качестве составного приложения на SalesForce.com. Для тех, кто не знаком с SalesForce.com, это платформа CRM в Интернете. Что это за составное приложение, просто показано внутри фрейма в отдельной вкладке. Поэтому, когда пользователь входит на сайт salesforce.com, он видит несколько вкладок. Мое приложение доступно, когда пользователь нажимает на вкладку моего приложения. Затем SalesForce.com передает URL-адрес для идентификатора сеанса salesforce моего приложения, который я могу использовать для доступа к данным salesforce без необходимости входа пользователя. Я, вероятно, потерял много пользователей, которые просто сказали бы: «Эй, это специфический вопрос salesforce.com». Ну, я думаю, что это не конкретный отдел продаж

Хорошо, продолжайте, люди советуют, чтобы аутентификация ASP.Net MVC 2 сохранялась в файле cookie на клиентском компьютере пользователя. Таким образом, в основном, я сохраняю идентификатор пользователя в cookie, а затем, если мне нужна информация о пользователе, я просто получаю его. В моем случае я вижу две проблемы: 1. Я использую информацию о клиенте довольно часто, поэтому я не хочу каждый раз запрашивать salesforce.com. Это хорошая идея, чтобы сериализовать и зашифровать информацию пользователя в куки? Кроме того, информация о пользователях - это объект с двумя свойствами объекта: одно содержит набор примитивов и перечислений для описания пользователя salesforce, а другой - набор примитивов и перечислений для описания пользователя в моем локальном приложении. 2. Мое приложение запускается изнутри iframe, и, насколько мне известно, будут проблемы с сохранением cookie на компьютере пользователя. Я не уверен, правда ли это. Также, когда пользователь выходит из Salesforce, мой файл cookie должен быть признан недействительным / удален с компьютера пользователя.

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

Но с точки зрения перехвата сеанса, если я зашифрую и сохраню идентификатор пользователя в cookie-файле и сохраню объект пользователя в кэше, а кто-то украдет сеанс, что кто-то тоже получает кэш и получает объект пользователя правильно?

С точки зрения истечения сеанса должен быть способ позаботиться о том, что я не уверен, как именно это делается, но я знаю, что это можно сделать в ASP.Net. Сохраняться в SQL-сервере, вероятно.

Буду очень признателен за помощь в определении того, что лучше всего делать с аутентификацией в ASP.net MVC 2 в текущем контексте (помните, что мое приложение - iframe).

С уважением, Kos

Answer 1

Я не знаком с ASP.Net MVC 2, но я хорошо знаю Salesforce, так что, надеюсь, я могу предложить несколько указателей. Я не совсем уверен, как ASP.Net MVC 2 будет поддерживать сеанс без любых файлов cookie, поэтому я предполагаю, что на компьютере пользователя хранится хотя бы легкий файл cookie с идентификатором ASP. который передается на сервер при каждом запросе для извлечения фактической кэшированной информации о пользователе и другой информации о сеансе. Если это так, я бы рекомендовал Salesforce отправить сгенерированный идентификатор дочернего сеанса SFDC в iframe, как вы делаете, и затем сохранить его на своем конце в сеансе ASP. Для последующих вызовов единственной вещью, которая будет передаваться назад и вперед на ваш сервер, будет легкий идентификатор сеанса ASP, который вы затем сможете использовать для доступа к идентификатору сеанса SFDC и другой информации.

Что касается вашего требования уничтожить сеанс ASP, когда пользователь выходит из системы, то не существует отличного способа сделать это напрямую (т. Е. Не подключаться к выходу из системы), но поскольку сгенерированный идентификатор сеанса SFDC был передан в ваш iframe был дочерним элементом сеанса пользовательского интерфейса, должен быть недействительным, когда пользователь выходит из системы. Это означает, что ваше приложение больше не сможет получить доступ к SFDC, но если вы также хотите завершить сеанс ASP, вы можете проверять сеанс ASP при каждом запросе, проверяя сеанс SFDC (отправьте простой вызов API, например, getServerTimestamp () ) и если вы хотите быть еще более агрессивным, вы могли бы опросить SFDC, чтобы проверить, действителен ли сеанс каждые n минут.