Авторизация пользователя на Azure

Question

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

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

Редактировать

Я посмотрел на элемент управления доступом к устройству, но это казалось излишним, так как я собирался создатьотдельный сайт для аутентификации, который, кажется, не имеет смысла.Будет ли аутентификация на основе утверждений иметь смысл отдельно?Как бы вы это сделали, если это произойдет?

Будет ли более целесообразным просто сохранить имя пользователя в файле cookie традиционным способом, а затем повторно запрашивать хранилище таблиц при каждом запросе, чтобы получить разрешения и т. Д.?Как будет работать хранение имени пользователя в Azure?

Здесь большое значение имеет стоимость, так как это очень маленький сайт (по стандартам Azure), но я хочу высокую производительность для небольшого числа пользователей.

Answer 1

Если вы хотите работать с достаточной доступностью, вам нужно запустить свой сайт с двумя экземплярами.Если вы работаете с двумя экземплярами, вам нужно использовать поставщика сессий, который не является InProc по умолчанию.Вы можете выбрать:

• Кэширование AppFabric (которое вы не хотите использовать, потому что оно слишком дорого, достаточно справедливо)
• Поставщик сеансов хранилища Azure. Не используйте это .Это интересный эксперимент, но это всего лишь пример кода, он медленный и плохо справляется с работой.
• Поставщик сеансов SQL Server.

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

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

Answer 2

Что ж, вы можете использовать кэш Azure App Fabric для хранения информации о сеансе. ASP.Net можно настроить на использование его в качестве резервного хранилища для своего состояния сеанса, как в обычном настраиваемом поставщике состояний сеанса.

В этой статье из MSDN показано, как его настроить:

http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx

Из вашего кода вы просто используете обычный способ ASP.Net, чтобы получить / установить состояние.

Имейте в виду, что это может быть дорого (45 долларов в месяц за 128 МБ кэша).