Аутентификация пользователей с помощью asp


Содержание

authentication — Аутентификация пользователя с помощью Restful asp.net Web api и защита API

Я участвую в разработке веб-API asp.net с интерфейсом frontularJS. Я проводил много исследований об этом примерно неделю. Я читал о oauth 2, owin и других. Но теперь это смущает, что лучше.

У меня есть пара вопросов и надеюсь, что вы, ребята, можете мне помочь.

1) В моем приложении — только зарегистрированный пользователь сможет иметь доступ к приложению через вход в систему с помощью электронной почты и пароля. Может ли кто-нибудь указать мне хороший ресурс или статью о том, как создать хорошую регистрацию и аутентификацию входа в систему с помощью API. Это достаточно безопасно, так как я собираю данные пользователя и сохраняю их.

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

Обратите внимание, что это не дублирующий вопрос, который я прошел через большую часть сообщения в stackoverflow и спрашивал об этом после того, как я не смог найти ответ.

Любое предложение или помощь по этому поводу приветствуются.

Спасибо за все ваши усилия по этой теме

    2 2
  • 18 май 2020 2020-05-18 10:13:10
  • GeekOnGadgets

2 ответа

Vs2013 шаблона проекта webapplication поставляется с хорошей настройкой owin. Я предлагаю изучить, что

  • 18 май 2020 2020-05-18 10:13:12
  • Ibrahim ben Salah

Вы можете использовать аутентификацию на основе токенов, используя Asp.Net Web API 2, OWIN, Identity Asp.Net и AngularJS.

API-интерфейс Asp.Net Web теперь полностью поддерживает OWIN. Катана — это реализация OWIN в Microsoft Outlook.

Asp.Net Web API теперь поддерживает авторизацию с использованием OAuth 2.0. OAuth становится возможной благодаря компонентам Microsoft OWIN.

Я смущен словом Identity, OWIN, OAuth. вот краткий обзор их.

Идентификация Asp.Net разработана для преодоления проблем системой членства asp.net. Asp.Net Identity позволяет нам использовать разные хранилища (хранилище таблиц, нет SQL) и позволяет нам использовать внешние поставщики удостоверений, поскольку использует OWIN.

OWIN — это разрыв жесткой связи b/w Asp.Net и IIS. OWIN — это просто спецификация. Katana — это реализация Microsoft OWIN. OWIN находится в конвейере запросов HTTP. OWIN-конвейер имеет компоненты промежуточного программного обеспечения, где мы можем упомянуть внешние механизмы входа.

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

Примечание: Здесь Asp.Net Identity не имеет ничего общего с OWIN, OAuth и наоборот. Это три отдельных понятия. Идентификация Asp.Net — это реализация Microsoft. OWIN, OAuth открыты стандартные понятия. Поскольку Microsoft внедрила OWIN, OAuth стала возможной.

Таким образом, Web API 2 использует токен-маркер OAuth вместо файлов cookie для проверки подлинности, что более корректно в мире веб-API. Поскольку он позволяет использовать множество конечных пользовательских устройств, таких как мобильные устройства.

В вашем случае вы можете использовать шаблоны по умолчанию, представленные в visual studio 2013.
1. Создайте новый проект и выберите веб-приложение Asp.Net.
2. Выберите веб-API или шаблон SPA.
3. Измените аутентификацию и выберите отдельные учетные записи пользователей.
4. Нажмите «ОК».

Теперь все настроено по умолчанию, чтобы использовать OWIN, Identity Asp.Net, OAuth. Из-за того, что мы используем аутентификацию на основе токенов, вы можете обнаружить, что в Account Controller нет метода входа в систему.

  • Чтобы зарегистрировать пользователей, используйте метод Register, доступный в AccountController
  • Для входа в систему вам необходимо отправить данные в следующем формате: http://example.com/token (который можно настроить в StartUp.Auth.cs)
    grant_type = пароль & имя пользователя = Alice & пароль = password123
  • После входа в систему мы получаем токен-носитель, который нам нужно отправить с заголовком авторизации с каждым запросом на доступ к защищенному ресурсу.

Поскольку вы используете потрясающую инфраструктуру frontend Framework AngularJs, вы можете сохранить токен-носитель в локальном хранилище, и вы можете написать службу перехватчика http, которая позаботится о передаче маркера-носителя с каждым запросом.

Здесь регистрация пользователя выполняется по идентификатору Asp.Net, где по умолчанию пользователь OAuthAuthorizationServer по-прежнему находится в папке «Поставщики».

Носильщики-носители, которые мы получаем, относятся не к конкретному клиенту, поэтому любой может их перехватить. Поэтому используйте их только через SSL.

Аутентификация в приложениях ASP.NET

Большинство web-сайтов работают в режиме анонимного доступа. Они содержат информацию, которую могут просматривать все желающие, и поэтому не проводят аутентификацию пользователей. Web-приложения ASP.NET предоставляют анонимный доступ к серверным ресурсам посредством назначения учетной записи анонимному пользователю. По умолчанию учетная запись для анонимного доступа имеет имя в виде IUSER _ имя компьютера.

ASP.NET исполняет web-приложения под учетной записью ASPNET. Это означает, что при выполнении задачи, не предусмотренной привилегиями пользователя (например, запись файла на диск), приложение получает отказ в доступе.
Идентификация пользователей применяется в тех случаях, когда нужно предоставить доступ к разделам web -приложения только для определенных пользователей. Это может быть Internet -магазины, форумы, закрытые разделы в корпоративных Intranet -сайтах и так далее.
Безопасность в приложениях ASP.NET основана на трех операциях:

  • Аутентификация – процесс идентификации пользователя для предоставления доступа к какому-то ресурсу приложения (разделу сайта, странице, базе данных, …). Аутентификация основана на проверке сведений о пользователе (например, имени и пароля);
  • Авторизация – процесс предоставления доступа пользователю на основе данных аутентификации;
  • Олицитворение (impersonalisation) – предоставление серверному процессу ASP.NET прав доступа клиента.

Существует три способа аутентификации пользователей в приложениях ASP.NET:

  • аутентификация Windows — применяется для идентификации и авторизации пользователей в зависимости от привилегий учетной записи пользователя. Работает аналогично обычным механизмам сетевой безопасности Windows и выполняется контроллером домена;
  • аутентификация Forms — пользователь вводит логин и пароль в Web -форме, после чего авторизация происходит по списку пользователей, хранящемуся, например, в базе данных. Применяется на большинстве Internet-сайтов при регистрации в Inernet -магазинах, форумах, пр;
  • аутентификация Passport — все пользователи имеют единое имя и пароль, используемые для сайтов, использующих данный тип авторизации. Пользователи регистрируются в службе Microsoft Passport.

Важно отметить, что аутентификация ASP.NET применяются только для web -форм (.aspx -файлы), контролов (.ascx -файды) и прочих ресурсов ASP.NET. HTML-файлы не входят в этот список. Для авторизации доступа к HTML -файлам нужно их зарегистрировать вручную!
Тип аутентификации указывается в конфигурационном файле Web.config :

По умолчанию применяется тип аутентификации Windows. Значение None имеет смысл устанавливать если используется собственная схема аутентификации или анонимный доступ (для повышения производительности).
Аутентификация Windows. Существует 4 типа аутентификации Windows : обычная ( basic ), краткая ( digest ), встроенная ( integated ) и на основе клиентских сертификатов SSL. Обычную и краткую аутентификацию применяют для идентификации имени пользователя и пароля, указываемом в диалоговом окне. Они хорошо работают в Internet , так как данные передаются по HTTP. Базовая аутентификация передает пароль и имя пользователя в кодировке Base 64, которую легко раскодировать. Для повышения безопасности можно использовать базовую аутентификацию совместно с SSL. Базовую аутентификация поддерживают большинство браузеров.
Краткая аутентификация является более безопасной, так как пароль шифруется по алгоритму MD 5. Она поддерживается браузерами Internet Explorer 5.0 и выше, либо на клиентской машине должен быть установлен. NET Framework. Кроме этого, учетные записи пользователей должны храниться в Active Directory.
Встроенная аутентификация применяется для идентификации учетных записей Windows и не может применяться в Internet , так как клиент и сервер должны пройти проверку контроллером домена. При этом пароли по сети не передаются, что увеличивает безопасность приложения. Этот тип аутентификации блокируется файрволами и работает только с Internet Explorer. Встроенная аутентификации немного медленнее, чем базовая или краткая.
Применение сертификатов SSL так же обычно применяется в Intranet , т.к. требует раздачи цифровых сертификатов. При этом типе аутентификации пользователям не нужно регистрироваться. Сертификаты можно сопоставить учетным записям пользователей в домене или Active Directory.

Для указания способа аутентификации нужно выполнить следующие действия:
1. Запустить диспетчер IIS
2. Щелкнуть правой кнопкой мыши по приложению и выбрать в контекстном меню Свойства.
3. В появившимся диалоге перейти на вкладку Безопасность каталога и нажать кнопку Изменить в разделе Анонимный доступ и проверка подлинности.

4. В диалоге Методы проверки подлинности указать тип аутентификации.

5. Указать права доступа к папке или отдельным файлам в папке Web -приложения. Обязательно нужно разрешить доступ для пользователя ASPNET.

Для поддержки URL-авторизации при Windows-аутентификации для защиты содержимого папок применяются Web.config файлы, находящиеся в этих папках. Структура файла такова (cимвол «*» означает всех пользователей):

В данном случае разрешен доступ для пользователя DENIS и запрещен доступ для всех остальных. Вместо имени пользователя может быть и название роли, к которой принадлежат пользователи – администраторы, менеджеры, …:

Если мы хотим защитить он неаутентифицированных пользователей папку полностью (например, папку, содержащую формы для администрирования сайта), то нужно разместить в ней файл Web.config с таким содержанием (cимвол «?» означает анонимных неавторизированных пользователей):

Если же мы хотим защитить только один файл (например, для подтверждения заказа в Internet -магазине), то в Web.config из корневой папки нужно добавить такие строки:

Приложение извлекает данные пользователей с помощью свойства Identity класса User. Это свойство возвращает объект, содержащий имя пользователя и роль.

bool authenticated = User.Identity.IsAuthenticated ;
string name = User.Identity.Name;
bool admin = User.IsInRole(«Admins»);

Forms-аутентификация

При использовании Forms-аутентификации запрос параметров регистрации (например, логина и пароля) происходит в web-форме. Регистрационная страница указывается в файле Web.config. При первом обращении к защищаемым страницам ASP.NET перенаправляет пользователя на страницу для ввода пароля. При успешной регистрации аутентификационные данные сохраняются в виде cookie и при повторном обращении к защищенным страницам регистрация не требуется.
Для того, чтобы использовать Forms-аутентификацию в файле Web.config в корневой папке приложения нужно указать страницу для ввода пароля:

При попытке просмотра защищенной страницы ASP.NET проверяет, есть ли аутентификационных cookie в запросе. Если cookie нет, то запрос перенаправляется на страницу для регистрации, если есть — ASP.NET дешифрует cookie и извлекает из него регистрационную информацию.

На форме находятся поля для ввода логина и пароля и флажок для сохраняемой регистрации. При нажатии кнопки «Войти» происходит поиск пользователя с таким логином и паролем. Если такой пользователь найден, вызывается функция FormsAuthentication.RedirectFromLoginPage (), в которой указывается идентификатор пользователя и флаг для сохраняемой регистрации. Если же нет – выводится сообщение об ошибке.

protected void btnLogin_Click(object sender, System.EventArgs e)
<
if (!IsValid) // проверяем правильность введенных данных
return;

OleDbConnection connection = GetDbConnection();

OleDbCommand command = new OleDbCommand(string.Format(«SELECT «, login, password), connection);

OleDbDataReader reader = command.ExecuteReader();
if (!reader.Read()) // пароль или логин неверны
<
lblError.Text = «Неверный пароль – попробуйте еще раз»;
return ;
>

string >
FormsAuthentication.RedirectFromLoginPage(id, chkbRememberLogin.Checked);
>
catch (OleDbException ex)
<
lblError.Text = «Ошибка базы данных»;
>
finally
<
connection.Close();
>
>

Аутентификации на основе ролей

Затем при каждом запросе нужно связывать учетные записи пользователей и роли. Обычно это делается в обработчике события AuthenticateRequest в файле Global.asax.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
<
HttpApplication appl = (HttpApplication)sender;

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

Параметры аутентификации

Когда сеансовый cookie возвращается в следующих после регистрации запросах, он автоматически обновляется, если время жизни истекло больше чем на половину. Время же жизни сохраняемых cookie равно 50 годам.
Можно указать имя аутентификационных cookie , поместив его в атрибут name (имя по умолчанию — ASPXAUTH ):

По умолчанию аутентификацонные cookie шифруются и проверяются. Уровень защиты можно указать через атрибут protection , значение по умолчанию которого All. Значение Validation предписывает только проверку cookie , а значение Encript – только шифрование. Полностью отключить защиту можно указав значение None. Отключать защиту имеет смысл если данные передаются по протоколу HTTPS.

Сброс forms-аутентификации

Сброс регистрации можно увидеть на многих сайтах. Для сброса аутентификации применяется метод FormsAuthentication.SignOut (). Он устанавливает дату окончания действия cookie на прошедшее время и cookie автоматически уничтожается.

Аутентификация Passport

Для использования Passport аутентификации в web -приложении нужно установить Passport SDK. Passport SDK предоставляется бесплатно для тестирования, но для коммерческого использования на сайте необходимо приобретать лицензию.
При обращении к приложению с Passport аутентификацией проверяется наличие cookie с данные Passport. Если такого файла нет, пользователь перенаправляется на страницу для регистрации Passport.
Для включения данного режима аутентификации в файле Web. config нужно указать следующее:

Для обязательной регистрации всех посетителей сайта в разделе autorization нужно запретить доступ неавторизированным пользователем:

Аутентификация пользователей с помощью токена аутентификации в строке запроса с помощью ASP.NET MVC

[Этот вопрос относится к ASP.NET MVC4, и речь идет о передовой практике — так что, пожалуйста, не предлагайте хаки.]

Я хочу аутентифицировать пользователей, используя токен аутентификации, отправленный в URL-адрес запроса. Он работает аналогично маркеру сброса пароля, за исключением того, что в этом случае он не переходит на страницу сброса, а вместо этого предоставляет доступ к некоторой части сайта. Идея состоит в том, чтобы отправить URL-адрес с токеном auth на проверенный адрес электронной почты пользователя. Пользователи могут щелкнуть ссылку и выполнить некоторые действия без ввода пароля.

Из-за коробки ASP.NET имеет атрибут [Authorize] и SimpleMembershipProvider — они, похоже, отлично работают, но они делают магию вуду под капотом (например, автоматически генерируют таблицы базы данных), поэтому я не знать, как расширить их, чтобы добавить этот токен аутентификации на основе ссылок.

Я не ожидаю точного ответа, но, пожалуйста, указывайте мне в правильном направлении.

Uf, широкий вопрос. Но я постараюсь хотя бы направить вас в правильном направлении.

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

Самый важный момент, который вы должны учесть, — это обычная аутентификация на основе токенов.

Создайте действие для входа, и в этом действии вы авторизуете пользователя, если он предоставил вам доступ, вы попросите FormsAuthentication создать AuthCookie. Для дальнейшего использования вы просто берете httpCookie.Value как свой токен аутентификации, который вы будете нести в строке запроса.

Вам необходимо реализовать Application_BeginRequest в Global.asax который будет обрабатывать эти токены строки запроса и переводить его в файл cookie. При таком подходе вы можете использовать всю инфраструктуру аутентификации ASP.NET Forms.

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

Вы должны просто использовать регулярное Action которое принимает HttpGet . Получив токен, немедленно его недействительно, чтобы он не мог использоваться снова. Кроме того, принимайте только токены, которые находятся в пределах вашего заранее определенного диапазона времени, например 24 или 72 часа.

Аутентификация и авторизация

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

Аутентификация подтверждает, что пользователь предоставил корректные данные для доступа в систему. Когда пользователь входит в систему (как правило, с помощью имени пользователя (логина) и пароля, но возможны и некоторые другие маркеры, такие как ключ SSH или зашифрованный ключ), он аутентифицирован.

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

Средства безопасности ASP.NET. Часть 2 — Авторизация

Первая часть статьи была посвящена аутентификации. В ней были рассмотрены теория аутентификации, разобраны все три способа аутентификации в среде .NET Framework. Во второй части статьи будет рассмотрен ещё один аспект компьютерной безопасности — авторизация. Для начала напомним, что же такое авторизация. Авторизация — это проверка прав доступа к определённому ресурсу, или проверка привилегий на выполнение определённых действий. В качестве примера можно привести ограничение прав доступа к определенным файлам. Давайте посмотрим на вопрос авторизации не глазами пользователя, а глазами программиста, который сам диктует правила игры.

Среда ASP.NET предоставляет два способа авторизации:

  1. Авторизация доступа к файлу
  2. Авторизация доступа к URL

Авторизация доступа к файлу

Суть авторизации доступа к файлу (File Authorization) заключается в настройке политики безопасности для конкретного файла в отдельности. При этом все параметры зависят от поддерживаемых средств безопасности Windows.

При авторизации доступа к файлу применяются списки контроля доступа ACL (Access Control List), в которых содержится информация о том, кому разрешён доступ к определённому ресурсу. Список контроля доступа последовательно просматривается на совпадение текущего зарегистрировавшегося пользователя с компонентами списка, если совпадений не будет, то система вернёт сообщение о том, что нет права доступа к данному ресурсу.

В связи с тем, что авторизация доступа к файлу основывается на системных механизмах ОС, при аутентификации тоже необходимо использовать аутентификацию Windows. Для этого в файле конфигурации проекта должна присутствовать следующая строка: Этот атрибут в проекте ASP.NET Web Application установлен по умолчанию, поэтому нет необходимости вручную вносить изменения в файл конфигурации.

Чтобы посмотреть, как действует этот механизм, создайте новый проект типа ASP.NET Web Application, переименуйте страницу ASP.NET в default.aspx и введите следующий код (листинг 1).

Листинг 1. default.aspx

Теперь откройте Explorer и найдите этот файл (по умолчанию он должен находиться по следующему адресу: C:\Inetpub\wwwroot\ \default.aspx). Далее щёлкните по нему правой кнопкой мыши и откройте окно свойств. Перейдите на вкладку Безопасность и добавьте в список допустимых имён группу администраторов (см. рисунок 1). Запустите Web-приложение, и если текущий пользователь является членом группы администраторов, то вы увидите дружелюбное приветствие, если же нет, то соответствующее сообщение об ошибке.


Рисунок 1. Установка авторизации доступа к файлу

Авторизация доступа к URL

Авторизация доступа к файлу — это старая технология, имеющая ряд недостатков: необходимость поддержки списков контроля доступа, более того, при передаче файлов по протоколу FTP списки ACL часто теряются, что зачастую приводит к нежелательным последствиям.

ПРИМЕЧАНИЕ

Сервер IIS поддерживает только авторизацию доступа к файлам, что в свою очередь сказалось на предыдущих версиях ASP, т. е. они тоже поддерживали лишь этот вид авторизации. Авторизация доступа к URL является новшеством, появившемся в ASP.NET. Кроме этого, если в настройках сервера IIS запрещен анонимный доступ, то управление авторизацией осуществляется сервером IIS, а если анонимный доступ к Web-узлу разрешён, то авторизацию уже контролирует ASP.NET.

Для использования авторизации доступа к URL сначала нужно настроить файл конфигурации проекта. За настройку авторизации отвечает тэг , который может содержать в себе только два типа элементов:

Каждый из этих элементов поддерживает 3 атрибута:

  • users — задаёт разделённый запятыми список имён пользователей.
  • roles — задаёт разделённый запятыми список имён пользовательских групп.
  • verbs — задаёт выражения HTTP, к которым применимы тэги и . Допустимыми значениями являются: GET, HEAD, POST и *, активизирующая все вышеперечисленные режимы.

Атрибут users поддерживает два специализированных обозначения:

  • » * » — все пользователи;
  • «?» — анонимные пользователи.

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

В вышеприведённом листинге мы сначала открыли доступ для всех, но потом закрыли его для не зарегистрировавшихся пользователей, т. е. работающих анонимно, и для всех членов группы BUILTIN\Guests . Здесь BUILTIN обозначает коллекцию встроенных ролей, поддерживаемых ASP.NET. Чтобы просмотреть их полный список, вы можете обратиться к следующему перечислению в окне ObjectBrowser Visual Studio.NET:

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

ПРИМЕЧАНИЕ

Для быстрой проверки работоспособности этого типа авторизации вы можете воспользоваться предыдущим примером (см. листинг 1). Для того, чтобы увидеть результат от соответствующего источника, удалите настройки авторизации доступа к файлу, т. е. отмените все установленные ограничения для файла default.aspx . После этого настройте файл конфигурации так, чтобы вашему текущему пользователю был запрещён доступ к узлу. Если всё было выполнено верно, то вы можете увидеть перед своими глазами картину, похожую на рисунок 2.

Рисунок 2. Отказано в доступе

Во всех предыдущих примерах файлов конфигурации проекта мы задавали ограничения на весь Web-узел, а часто нужно задать эти параметры лишь для определённых директорий или файлов. Для решения этой проблемы в файле конфигурации проекта ASP.NET поддерживается специальный тэг, который ограничивает распространение политики авторизации — это тэг . Этот элемент имеет всего два атрибута:

  • path — задаёт путь к ресурсу, для которого будут применены параметры авторизации;
  • allowOverride — разрешает или запрещает (значения true или false соответственно) перекрывать параметры настройки тэга location данными из других файлов конфигурации.

Предположим, у нас есть проект с тремя папками, в каждой из которых содержится информация для соответствующих пользователей, и нам нужно разграничить доступ к информации между группами пользователей. Следующий фрагмент (листинг 2) файла Web.config демонстрирует применение тэга location для достижения этой цели.

Листинг 2. Разграничения прав доступа пользователей

В данном примере параметры авторизации проекта настроены так, что в корневом каталоге доступ разрешён всем: предполагается, что в нём находится страница регистрации, через которую должен пройти каждый ещё не зарегистрировавшийся пользователь. Следующий тэг определяет настройки безопасности для файла admin.aspx, расположенного в папке admin_zone: к нему доступ открыт лишь членам группы Administrators. Далее указываются настройки безопасности для папки user_zone, куда разрешён доступ членам групп Users и Administrators. И, наконец, последний путь — это папка guest_zone: ко всем ресурсам, содержащимся в ней, могут обратиться анонимные пользователи и пользователи, являющиеся членами двух уже ранее названных групп — Users и Administrators.

Ролевая безопасность с применением аутентификации на основе формы

Все предыдущие примеры были ориентированы на применение средств безопасности Windows: это была и аутентификация Windows, имена пользователей и групп тоже принадлежали политике безопасности ОС. Но в некоторых случаях возникает необходимость применения в Web-проекте аутентификации на основе формы, а также выбор такого средства авторизации, которое бы не зависело от настроек безопасности сервера. И такое средство существует: вы по-прежнему продолжаете использовать аутентификацию формой, авторизацию доступа к URL, но информация о пользователях и ролях хранится не в каталоге безопасности Windows, а в любом другом месте.

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

Листинг 3. Web.config

В этом примере мы поместили в одну процедуру две операции проверки: одна — аутентификации, другая — авторизации. Сначала мы проходим аутентификацию, запрашивая данные на пользователя с таким-то именем и паролем из базы. Если пользователь не был найден, выводим соответствующее сообщение об ошибке (см. 4 строку снизу). Если же пользователь обнаружен, то мы определяем его роли, опять запрашивая информацию из базы данных. На основе полученных сведений о ролях формируется аутентификационный билет, который впоследствии шифруется и сохраняется в cookie-файле. И, наконец, пользователь благополучно возвращается на страницу default.aspx.

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

Листинг 7. default.aspx

После создания этого простого Web-узла вы сможете собственными глазами увидеть плоды своего труда. В приведённом коде указаны все инструкции, необходимые для создания действующей системы безопасности для сайта на базе аутентификации формой и авторизации с помощью URL.

Заимствование полномочий

Заимствование полномочий — это такой режим работы, при котором приложение ASP.NET функционирует от имени конкретного пользователя. Казалось бы, какой смыл вводить заимствование полномочий, если при аутентификации Windows пользователь и так заходит под конкретной учётной записью? Но всё дело в том, что идентификатор пользователя при аутентификации и идентификатор пользователя при заимствовании полномочий — это разные вещи, и применяются они соответственно для получения различной информации.

По умолчанию режим заимствования полномочий в среде ASP.NET отключён. Для его активизации нужно добавить в файл Web.config тэг и присвоить его атрибуту impersonate значение true. Следующий фрагмент файла конфигурации проекта демонстрирует, как это должно выглядеть:

Для демонстрации работы этого режима, используйте следующий код (листинг 8) в странице default.aspx:

В обработчике события загрузки формы для получения идентификатора пользователя объекта WindowsIdentity используется метод GetCurrent, возвращающий идентификатор учётной записи, от имени которой функционирует процесс ASP.NET.

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

ПРИМЕЧАНИЕ

Проследите, чтобы в этом примере анонимный доступ был запрещён

Рисунок 3. Запрещённые заимствование полномочий и анонимный доступ

Теперь, если вы активизируете заимствование полномочий, то увидите результат, представленный в таблице 1.

Таблица 1. Включенное заимствование полномочий и отключенный анонимный доступ

IsAuthenticated True
Authentication type Negotiate
Name BIGDRAGON\B@k$
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\B@k$

Как видите, результаты одинаковые, поскольку оба объекта получают информацию о текущем пользователе. Но предыдущие два примера были ориентированы на условия с запрещённым анонимным доступом для аутентификации средствами Windows. Если разрешить анонимный доступ к приложению, то объект User.Identity не вернёт никакого имени пользователя, а его свойство IsAuthenticated будет иметь значение False. В этом нет ничего удивительного, т. к. если в системе аутентификации Windows разрешён анонимный доступ, то пользователь работает анонимно, то есть не проходит аутентификацию.

ПРИМЕЧАНИЕ

Чтобы разрешить анонимный доступ, найдите в IIS ваше приложение и откройте его окно свойств, перейдите во вкладку Безопасность каталога и в рамке, содержащей настройки анонимного доступа, нажмите Изменить . В появившемся окне активизируйте переключатель Анонимный доступ .

В это же время у объекта WindowsIdentity свойство IsAuthenticated будет иметь значение True, а в качестве имени пользователя будет стоять строка следующего формата: IUSR_ , как показано в таблице 2.

Таблица 2. Заимствование полномочий и анонимный доступ разрешены

IsAuthenticated False
Authentication type
Name
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\IUSR_BIGDRAGON

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

Если вы были внимательны при выполнении операций по разрешению/запрету анонимного доступа, то могли заметить, что в поле Имя пользователя была как раз подставлена строка вышеуказанного формата: IUSR_ (рис. 4).

Рисунок 4. В поле Имя пользователя содержится строка, определяющая имя процесса ASP.NET при анонимном доступе

Кроме того, в среде ASP.NET предусмотрена возможность указания, от кого именно заимствовать полномочия. С этой целью в тэге предусмотрен атрибут userName, в котором и указывается имя пользователя, у которого необходимо заимствовать полномочия.

ПРИМЕЧАНИЕ

В атрибуте userName имя пользователя указывается вместе с именем домена

В следующем фрагменте из файла Web.config, показано, как это должно выглядеть на практике:

После запуска тестового приложения с такой конфигурацией на выполнение, состояние объекта User.Identity останется неизменным, а вот в свойстве name объекта WindowsIdentity вместо строки формата IUSR_ появится имя, указанное в атрибуте userName тэга из файла конфигурации проекта, как показано в таблице 3.

Таблица 3. Процесс ASP.NET работает от имени конкретного пользователя

IsAuthenticated False
Authentication type
Name
IsAuthenticated True
Authentication type NTLM
Name BIGDRAGON\AlBa

Если вы отмените анонимный доступ, то объект User.Identity будет содержать идентификатор зарегистрированного пользователя, а в объекте WindowsIdentity по-прежнему будет оставаться имя пользователя, переданное через атрибут userName.

На этом закончим изучение авторизации как средства безовасности среды ASP.NET. Дальнейшее изучение механизма авторизации требует изучения средств авторизации Windows. Среди них можно выделить списки контроля доступа на низком и высоком уровне, контроль доступа архитектуры клиент/сервер, ролевая безопасность Windows и так далее.

Если эта тема вас действительно заинтересовала, то вы можете найти массу материала в библиотеке MSDN:

  • Темы безопасности в рамках ASP.NET доступны в следующей ветке библиотеки MSDN: .NET Development/.NET Security;
  • По вопросам безопасности всей системы в целом следует обращаться к разделу Security/Security (General)/SDK Documentation.

Если у вас нет MSDN-библиотеки, то к её самому свежему изданию можно обратиться через интернет по адресу: http://msdn.microsoft.com/library/.

В третьей, заключительной части данной статьи, мы рассмотрим очень актуальную и интересную тему — криптографию. Кроме теории и алгоритмов криптографии мы рассмотрим с различных сторон средства шифрования, предоставляемые платформой .NET Framework, и создадим простенький метод шифрования.

Аутентификация пользователей с помощью asp

Volume 25 Number 08

Federated Identity — Passive Authentication for ASP.NET with WIF

The goal of federated security is to provide a mechanism for establishing trust relationships between domains so that users can authenticate to their own domain while being granted access to applications and services belonging to another domain. This makes authentication techniques like single sign-on possible, removes the need to provision and manage duplicate accounts for users across applications and domains, and significantly lowers the cost to extend applications to trusted parties.

In a federated security model, an Identity Provider (IdP) performs authentication and supplies a Security Token Service (STS) to issue security tokens. These tokens, in turn, assert information about the authenticated user: her identity and possibly other information including roles and more granular access rights. In a federated world, this information is referred to as claims, and claims-based access control is central to a federated security model. In this model, applications and services authorize access to features and functionality based on claims from trusted issuers (the STS).

Platform tools like Windows Identity Foundation (WIF) make it much easier to support this type of identity federation. WIF is an identity model framework for building claims-based applications and services, and for supporting SOAP-based (active) and browser-based (passive) federation scenarios. In the article “Claims-Based Authorization with WIF,” in the November 2009 issue of MSDN Magazine, I focused on using WIF with Windows Communication Foundation (WCF). In that article I described how to implement claims-based security models for WCF services and how to migrate to identity federation.

In this follow-up article I will focus on passive federation. I will explain the flow of communication for passive federation, show you several techniques for enabling federation in your ASP.NET applications, discuss claims-based authorization techniques for ASP.NET, and talk about single sign-on and single sign-out scenarios. Along the way, I will explain the underlying WIF features and components that support passive federation scenarios.

Passive Federation Basics

Passive federation scenarios are based on the WS-Federation specification. This describes how to request security tokens and how to publish and acquire federation metadata documents, which makes establishing trust relationships easy. WS-Federation also describes single sign-on and sign-out procedures and other federation implementation concepts.

While WS-Federation discusses many details about federation, there are sections devoted to browser-based federation that rely on HTTP GET and POST, browser redirects and cookies to accomplish the goal.

Some aspects of passive federation messaging are based closely on the WS-Trust specification. For example, passive federation employs a browser-compatible form of Request Security Token (RST) and RST Response (RSTR) when a security token is requested of an STS. In the passive federation scenario, I’ll call the RST a sign-in request message and the RSTR a sign-in response message. The WS-Trust specification focuses on SOAP-based (active) federation, such as between Windows clients and WCF services.

A simple passive federation scenario is illustrated in Figure 1.

Figure 1 A Simple Passive Federation Scenario

Users authenticate to their domain and are granted access to a Web application according to their roles. The participants in this authentication scheme include the user (the subject), a Web browser (the requester), an ASP.NET application (the relying party or RP), an IdP responsible for authenticating the users within its domain and an STS belonging to the user’s domain (IP-STS). A sequence of browser redirects ensures that the user is authenticated at her domain prior to accessing the RP.

The user browses to the RP application (1) and is redirected to her IdP to be authenticated (2). If the user has not yet been authenticated at the IdP, the IP-STS may present a challenge or redirect her to a login page to collect credentials (3). The user supplies her credentials (4) and is authenticated by the IP-STS (5). At this point, the IP-STS issues a security token according to the sign-in request, and the sign-in response containing the token is posted to the RP via browser redirect (6). The RP processes the security token and authorizes access based on the claims it carries (7). If successfully authorized, the user is presented with the page she originally requested and a session cookie is returned (8).

Implementing this passive federation scenario with WIF and ASP.NET involves only a few steps:

  1. Establish a trust relationship between the RP and IdP (IP-STS)
  2. Enable passive federation for the ASP.NET application
  3. Implement authorization checks to control access to application features In the next sections I’ll discuss the features of WIF that support passive federation, walk through the steps to configure this simple scenario, and then explore other practical considerations for this and other scenarios.

WIF Features for Passive Federation

Before discussing implementation, let me review the features of WIF specifically useful for identity federation within your ASP.NET applications. To begin with, WIF supplies the following useful HTTP modules:

  • WSFederationAuthenticationModule (FAM): Enables browser-based federation, handling redirection to the appropriate STS for authentication and token issuance, and processing the resulting sign-in response to hydrate the issued security token into a ClaimsPrincipal to be used for authorization. This module also handles other important federation messages such as sign-out requests.
  • SessionAuthenticationModule (SAM): Manages the authenticated session by generating the session security token that contains the ClaimsPrincipal, writing it to a cookie, managing the lifetime of the session cookie and rehydrating the ClaimsPrincipal from the cookie when it’s presented. This module also maintains a local session token cache.
  • ClaimsAuthorizatonModule: Provides an extensibility point to install a custom ClaimsAuthorizationManager that can be useful for centralized access checks.
  • ClaimsPrincipalHttpModule: Creates a ClaimsPrincipal from the current user identity attached to the request thread. In addition, provides an extensibility point to install a custom ClaimsAuthenticationManager that can be useful for customizing the ClaimsPrincipal to be attached to the request thread.

ClaimsPrincipalHttpModule is most useful for applications without passive federation. You can think of it as a useful tool for implementing a claims-based security model in the ASP.NET application prior to moving to passive federation. I discussed this technique for WCF in my previous article.

The other three modules are typically used together for passive federation—although ClaimsAuthorizationModule is optional. Figure 2 illustrates how these core modules fit into the request pipeline and their functions in a typical federated authentication request.

Figure 2 WIF Components and HTTP Modules Engaged in Passive Federation

Keeping in mind the flow of passive federation from Figure 1, when the user first browses to a protected page in the RP (1), access to the application will be denied. The FAM processes unauthorized requests, produces the sign-in message and redirects the user to the IP-STS (2). The IP-STS authenticates the user (3), produces a sign-in response that includes the issued security token, and redirects back to the RP application (4).

The FAM processes the sign-in response—ensuring that the response contains a valid security token for the authenticated user—and hydrates a ClaimsPrincipal from the sign-in response (5). This will set the security principal for the request thread and HttpContext. The FAM then uses the SAM to serialize the Claims­Principal to an HTTP cookie (6) that will be presented with subsequent requests during the browser session. If ClaimsAuthorizationModule is installed, it will invoke the configured ClaimsAuthorization­Manager, providing an opportunity to perform global access checks (7) against the ClaimsPrincipal prior to accessing the requested resource.

Once the requested resource is presented, access control can be implemented with traditional ASP.NET login controls, IsInRole checks and other custom code that queries the user’s claims (8).


On subsequent requests the session token is presented with the cookie previously written by the SAM (9). This time the SAM is engaged to validate the session token and rehydrate the Claims­Principal from the token (10). The FAM is not engaged unless the request is a sign-in response, a sign-out request, or if access is denied, which can happen if the session token is not present or has expired.

In addition to these modules, there are two ASP.NET controls that are also useful in passive federation:

  • FederatedPassiveSignIn Control: Can be used in lieu of the FAM if the application will redirect all unauthorized calls to a login page that hosts this control only when authentication is required. This assumes the user will interact with the sign-in process—useful in step-up authentication scenarios where the user is prompted for credentials, possibly additional credentials from the original login, as required by the application. The control handles redirection to the STS, processing the sign-in response, initializing the ClaimsPrincipal from the response and establishing a secure session by leveraging functionality exposed by the FAM and SAM.
  • FederatedPassiveSignInStatus Control: This control provides an interactive way for the user to sign in or sign out from the RP application, including support for federated sign-out.

Figure 3 illustrates how the flow of communication changes when the FederatedPassiveSignIn control is employed. The application relies on Forms authentication to protect resources and redirect to the login page, which hosts the control (1). The user clicks the FederatedPassiveSignIn control (or can be redirected to it automatically), which triggers a redirect to the STS (2). The control page receives the response from the STS, relying on the FAM and the SAM to process the sign-in response (3), hydrate the Claims­Principal and write the session cookie (4). When the user is redirected to the originally requested page (5), the SAM is engaged to validate the session cookie and hydrate the ClaimsPrincipal for the request. At this point, the ClaimsAuthorizationModule and that page can perform their authorization checks as illustrated in Figure 2.

Figure 3 Passive Federation with the FederatedPassive­-SignIn Control

Both the FAM and SAM rely on the appropriate Security­TokenHandler type to process incoming tokens. When a sign-in response arrives, the FAM iterates through SecurityTokenHandlerCollection looking for the correct token handler to read the XML token. In a federated scenario this will typically be Saml11Security­TokenHandler or Saml2Security­TokenHandler—though other token formats may be employed if you add custom token handlers. For the SAM, SessionSecurity­TokenHandler is used to process the session token associated with the session cookie.

Several identity model configuration settings are important to the flow of passive federation—and are used to initialize the FAM and the SAM and the FederatedPassiveSignIn control (although the latter also exposes properties configurable from the Visual Studio designer). Programmatically, you can supply an instance of the Service­Configuration type from the Microsoft.IdentityModel.Configuration namespace, or you can supply declarative configuration in the section. Figure 4 summarizes identity model settings, many of which will be discussed in subsequent sections.

Figure 4 Summary of the Essential Elements

Section Description
Specify a list of trusted certificate issuers. This list is primarily useful for validating the token signature so that tokens signed by un-trusted certificates will be rejected.
Specify a list of valid audience URIs for incoming SAML tokens. Can be disabled to allow any URI, though not recommended.
Customize configuration settings for token handlers or supply custom token handlers to control how tokens are validated, authenticated, and serialized.
Adjust the allowed time difference between tokens and application servers for token validity. The default skew is 5 minutes.
Control how certificates are validated.
Supply a service certificate for decrypting incoming tokens.
Supply a custom ClaimsAuthenticationManager type to customize or replace the IClaimsPrincipal type to be attached to the request thread.
Supply a custom ClaimsAuthorizationManager type to control access to functionality from a central component.
Supply settings specific to passive federation.

Enabling Passive Federation

WIF makes it easy to configure passive federation for your ASP.NET applications. An STS should supply federation metadata (as described in the WS-Federation specification) and WIF supplies a Federation Utility (FedUtil.exe), which uses federation metadata to establish trust between an RP and an STS (among other features useful to both active and passive federation scenarios). You can invoke FedUtil from the command line or from Visual Studio by right-clicking on the RP project and selecting Add STS reference.

You’ll complete the following simple steps with the FedUtil wizard:

  • The first page of the wizard allows you to confirm the configuration file to be modified by the wizard and the RP application URI.
  • The second page requests the path to the federation metadata XML document for the STS with which the RP will establish trust.
  • The third page allows you to supply a certificate to be used for decrypting tokens.
  • The final page shows a list of claims offered by the STS—which you can use to plan access control decisions, for example.

When the wizard steps are completed, FedUtil modifies the project to add a reference to the Microsoft.IdentityModel assembly. It also modifies the web.config to install the FAM and SAM modules and to supply identity model configuration settings for those modules. The application now supports passive federation and will redirect unauthorized requests to the trusted STS.

There’s an assumption here that the STS has prior knowledge of the RP, will thus issue tokens for authenticated users trying to access the RP, and of course that it has the public key the RP requires the STS to use to encrypt tokens. This is an easy way to get your ASP.NET applications initially set up for federation. Of course, it helps to understand how to set this up from scratch in case adjustments are required, and how to go beyond the basic settings enabled by the wizard. I’ll focus on the “from scratch” approach from here on in.

Without using FedUtil, you need to manually add a reference to the Microsoft.IdentityModel assembly, and manually configure the FAM and the SAM modules along with the necessary identity model settings. HTTP modules are added to two sections: system.web for Internet Information Services (IIS) 6 and system.webServer for IIS 7. Assuming the application is hosted in IIS 7, the WIF modules are configured as follows:

By default this configuration will only protect resources with extensions explicitly mapped to be handled by the ASP.NET pipeline (.aspx, .asax, and so on). To protect additional resources with federated authentication, you should map those extensions to the ASP.NET pipeline in IIS, or you can set runAllManagedModulesForAllRequests to true in the modules setting (IIS 7 only) as follows:

For the FAM to kick in, you must also set the ASP.NET authentication mode to None and deny anonymous users access to application resources:

Both modules rely on identity model configuration settings described in Figure 4, a typical example of which is shown in Figure 5. Most of these settings are generated for you by FedUtil, with the exception of certificateValidation and a few of the settings within federatedAuthentication. I typically recommend using PeerTrust certificate validation mode—which means that you explicitly add all trusted certificates, including that of the trusted issuer, to the local machine’s TrustedPeople store.

Figure 5 Identity Model Configuration for Passive Federation

You should typically require HTTPS/SSL for passive federation to protect the issued bearer token from man-in-the-middle attacks, and require HTTPS/SSL for session cookies. By default, cookies are hidden from script, but it’s an important setting, which is why I call it out in Figure 5.

As for the name and path of the cookie, the name defaults to FedAuth, the path to the application directory. It can be useful to specify a unique name for the cookie, in particular if many RP applications in the solution share the same domain. Conversely, you can choose to specify a generic path when you want cookies to be shared across several apps on the same domain.

You will typically use FedUtil to configure your ASP.NET applications for passive federation using the FAM and SAM, then tweak the appropriate settings according to the requirements of the solution. You can also use the PassiveFederationSignIn control in lieu of the FAM as illustrated in Figure 3. The control can either load its settings from the microsoft.identityModel section, or you can set properties directly on the control.

The control approach is useful if you want unauthorized requests to be redirected to a login page where the user can explicitly sign in by clicking the control, rather than having the FAM automatically redirect to the STS. For example, if the user may belong to more than one identity provider (home realm), the login page could provide a mechanism for her to indicate her home realm prior to redirecting to the STS. I’ll discuss home realm discovery shortly.

Passive Token Issuance

As mentioned earlier, passive federation relies on HTTP GET and POST and browser redirects to facilitate communication between the RP and STS. Figure 6 shows the primary request parameters involved in the sign-in request and sign-in response during this process.

Figure 6 Primary Sign-In Request and Response Parameters Involved in Passive Federation Requests

When the STS receives the sign-in request, it will verify that it knows about the RP by checking the wtrealm parameter against its list of known RP realms. Presumably the STS will have prior knowledge of the RP, the certificate required for token encryption, and any expectations with respect to the desired claims to be included in the issued token. The RP can indicate which claims it requires if it supplies the optional wreq parameter with a full sign-in request, and the STS can optionally respect that list or decide autonomously which claims to grant based on the authenticated user.

In a simple federation scenario like that described in Figure 1, there is a single RP and a single IP-STS responsible for authenticating users. If the IP-STS authenticates users against a Windows domain, it might issue role claims such as Admin, User or Guest. The assumption is that these roles have meaning to the RP for authorization. In the next section, I’ll assume these roles suffice and discuss authorization techniques. Following that I will discuss claims transformation at the RP to convert STS claims into something more useful for authorization as needed.

Claims-Based Authorization

As I discussed in my previous article, role-based security in the .NET Framework expects that a security principal is attached to each thread. The security principal, based on IPrincipal, wraps the identity of the authenticated user in an IIdentity implementation. WIF supplies ClaimsPrincipal and ClaimsIdentity types based on IClaimsPrincipal and IClaimsIdentity (which ultimately derive from IPrincipal and IIdentity). When the FAM processes the sign-in response, it hydrates a ClaimsPrincipal for the issued security token. Likewise, the SAM hydrates a ClaimsPrincipal for the session cookie. This ClaimsPrincipal is the heart of WIF authorization for your ASP.NET application.

You can use any of the following approaches to authorization:

  • Use location-specific authorization settings to restrict access to directories or individual application resources.
  • Use ASP.NET login controls, such as the LoginView control, to control access to functionality.
  • Use ClaimsPrincipal to perform dynamic IsInRole checks (for example, to dynamically hide or show UI elements).
  • Use the PrincipalPermission type to perform dynamic permission demands, or the PrincipalPermissionAttribute if declarative permission demand seems appropriate on a particular method.
  • Provide a custom ClaimsAuthorizationManager to centralize access checks in a single component, even prior to loading the requested resource.

The first three of these options rely on the IsInRole method exposed by the ClaimsPrincipal type. You must select a role claim type fitting for the IsInRole check so that the correct claims will be used to control access. The default role claim type for WIF is:

If ClaimsPrincipal includes defined claims, the role claim type will match the default. Later, I will discuss permission claims in the context of claims transformation. When these are utilized, you should specify the permission claim type as the role claim type so that IsInRole will be effective.

You can control access to specific pages or directories globally from the web.config file. In the application root, supply a location tag specifying the path to protect, allow a list of acceptable roles and deny access to all other users. The following allows only Administrators to access files beneath the AdminOnly directory:

As an alternative, you can put a web.config in any subdirectory and specify authorization rules. Placing the following configuration in the AdminOnly directory achieves the same result:

To dynamically hide and show UI components or otherwise control access to features within a page, you can leverage the role-based features of controls such as the LoginView. However, most developers prefer to explicitly set control properties for access control during page load for more granular control. To do this, you can call the IsInRole method exposed by Claims­Principal. You can access the current principal through the Thread.CurrentPrincipal static property as follows:

Aside from explicit IsInRole checks at runtime, you can also write classic role-based permission demands using the Principal­Permission type. You initialize the type with the required role claim (the second constructor parameter), and when Demand is called, the IsInRole method of the current principal is called. An exception is thrown if the claim is not found:

This approach is useful for rejecting a request with an exception, when the appropriate roles aren’t present.

It’s also useful to centralize authorization checks common to all requested resources. Sometimes, if you have an access control policy—for example, rules stored in a database—you can use a central component to read those rules to control access to features and functionality. For this, WIF supplies a ClaimsAuthorizationManager component that you can extend. Recall from my previous article that you can configure this type of custom component in the identity model section:

Figure 7illustrates a custom ClaimsAuthorizationManager that verifies the presence of the name claim and whether the requested resource is within the AdminsOnly directory requires the Administrators role claim.

Figure 7 Custom ClaimsAuthorizationManager Implementation

The CustomClaimsAuthorizationManager overrides Check­Access to provide this functionality. This method supplies an AuthorizationContext parameter, which provides information about the request action (for passive federation this is an HTTP verb such as GET or POST), the requested resource (a URI), and the Claims­Principal, which is not yet attached to the request thread.

Claims Transformation

Often, the claims issued by the IP-STS, although useful for describing the authenticated user, are not relevant to the authorization requirements of the RP. It isn’t the IdP’s job to know what type of roles, permissions or other fine-grained artifact is necessary for authorization at each RP. It’s the IdP’s job to grant claims that are relevant to the identity provider domain, claims that the IdP can assert about the authenticated user.

As such, the RP may need to transform claims from the IP-STS into something more relevant for authorization. This implies that the RP may map the user identity (perhaps by user name or UPN) to a set of RP claims. Assuming the IP-STS grants default role claims, Figure 8 lists a possible set of permission claims that the RP could issue based on each incoming role claim. The permission claim type may be a custom claim type defined by the RP such as:

A good place to transform incoming IP-STS claims is with a custom ClaimsAuthenticationManager. You can install a custom ClaimsAuthenticationManager by adding the following to the microsoft.identityModel section:

Figure 9shows a sample CustomClaimsAuthenticationManager that transforms incoming role claims granted by the IP-STS into permission claims relevant to the RP.

Figure 8 Transforming Role Claims to Permission Claims at the RP

Role Claim Permission Claims
Administrators Create, Read, Update, Delete
Users Create, Read, Update
Guest Read

Figure 9 Custom Claims Transformation at the RP

For IsInRole checks (as described earlier) to work, you must provide the permission claim type as the role claim type. In Figure 9, this is specified when the ClaimsIdentity is constructed because the RP is creating the ClaimsIdentity.

In the case where incoming SAML tokens are the source of claims, you can provide the role claims type to the SecurityTokenHandler. The following illustrates how to declaratively configure the Saml11SecurityTokenHandler to use the permission claim type as the role claim type:

SAML token handlers have a samlSecurityTokenRequirement section where you can provide a setting for the name and role claim type, along with other settings related to certificate validation and Windows tokens.

Home Realm Discovery

So far, I have focused on a simple federation scenario with a single IP-STS. The assumption is that the RP will always redirect to a particular IP-STS to authenticate users.

In the world of federation, however, the RP may trust multiple token issuers from several domains. A new challenge presents itself in this case because the RP must decide which IP-STS should authenticate users requesting access to resources. The domain to which users authenticate is known as the user’s home realm, and thus this process is called home realm discovery.

There are a number of mechanisms an application may use for home realm discovery:

  • As in the current example, the home realm is known in advanced and so requests are always redirected to a particular IP-STS.
  • Users may browse to the RP from another portal, which can provide a query string to indicate the home realm for users from that portal.
  • The RP may require that users land on a particular entry page for each home realm. The landing page could assume a particular home realm.
  • The RP may be able to determine the home realm by the IP address of the request or some other heuristic.
  • If the RP can’t determine the home realm from one of the aforementioned techniques, it can present a UI where the user can select the home realm or provide information that helps the RP determine this.
  • If the RP supports information cards, the selected card can drive authentication to the appropriate home realm using active federation.
  • The WS-Federation briefly describes how one might implement a discovery service for resolving the home realm, but there isn’t a well-defined specification for this.

No matter how the home realm is discovered, the goal is to redirect the user to authenticate with the correct IP-STS. There are a few possible scenarios here. In one scenario, the RP may need to dynamically set the issuer URI so that the sign-in request is sent to the correct IP-STS. In this case, the RP must list all trusted IP-STS in the trustedIssuers section, for example:

In addition, you can override the RedirectingToIdentityProvider event exposed by the FAM and, using relevant heuristics, determine the correct URI for the STS. To do this, place the following code in the Global.asax implementation:

The other scenario involves passing the home realm parameter (whr) with the sign-in request to the primary STS. The RP may, for example, have a Resource STS (R-STS or RP-STS) responsible for claims transformation. The RP-STS doesn’t authenticate users (it’s not an IdP), but it has trust relationships with one or more other IdPs.

The RP has a trust relationship with the RP-STS, and will always respect tokens issued by the RP-STS. The RP-STS is responsible for redirecting to the correct IdP for each request. The RP-STS can determine the correct IP-STS to redirect to as in the code just described, but another option is for the RP to supply information about the home realm, passing this in the home realm parameter to the RP-STS. In this case, the RP dynamically sets the home realm parameter:

The RP-STS uses this parameter to redirect to the correct IP-STS and subsequently transforms claims from the IP-STS into claims relevant to the RP.

Single Sign-On and Single Sign-Out

Single sign-on and single sign-out are important parts of federation. Single sign-on is a feature that allows authenticated users to access multiple RP applications while authenticating only once. Single sign-out, as it implies, facilitates sign-out from all RP applications and any relevant STS chain with a single request.

In a simple federation scenario like that shown in Figure 1, the user authenticates to the IP-STS and is authorized at the RP based on the issued security token. Post-authentication, the user has a session cookie for the STS and another for the RP. Now, if the user browses to another RP, she will be redirected to the IP-STS for authentication—assuming both RP applications trust the same IP-STS. Because the user already has a session with the IP-STS, the STS will issue a token for the second RP without prompting for credentials. The user now has access to the second RP and has a new session cookie for the second RP.

As I’ve discussed, WIF supplies the SAM to write out the session cookie for authenticated users. By default, this session cookie is issued for the relative application address for the domain, and its base name is FedAuth. Because federated session cookies can be large, the token is usually split into two (or more) cookies: FedAuth, FedAuth1, and so on.

If you are hosting more than one application at the same domain, as part of the federation scenario, the default behavior would be that the browser has a FedAuth cookie for each RP (see Figure 10). The browser sends only those cookies associated with the domain and path for the request.

Figure 10 Session Cookies Associated with Each RP and the STS

This default behavior is generally fine, but sometimes it’s necessary to supply a unique, per-application name for each session cookie—in particular if they’re hosted on the same domain. Or multiple applications at the same domain may share a session cookie, in which case you can set the cookie path to “/”.

If the session cookie expires, the browser will remove it from the cache and the user will be redirected once again to the STS for authentication. Separately, if the issued token associated with the session cookie has expired, WIF will redirect to the STS for a new token.

Sign-out is more explicit—usually driven by the user. Single sign-out is an optional feature of the WS-Federation specification that suggests the STS should also notify other RP applications for which it has issued tokens of the sign-out request. This way, the session cookie is removed for all applications the user browsed to during the single sign-on session. In a more complex scenario, where multiple STSs are involved, the primary STS receiving the sign-out request should also notify other STSs to do the same.

For the purpose of this discussion, I will focus on what you should do at the RP to facilitate federated single sign-out. You can place the FederatedPassiveSignInStatus control on any page from which you want to support sign-in and sign-out and the control will automatically indicate its state. Once signed-in, the control presents a link, button or image for signing out.

When you click the control, it will handle sign-out according to the SignOutAction property, which can be Refresh, Redirect, RedirectToLoginPage or FederatedPassiveSignOut. The first three delete the session cookie for the application, but do not notify the STS of the sign-out request. When you select the FederatedPassiveSignOut setting, the control will call SignOut on WSFederationAuthenticationModule. This ensures that federated session cookies are removed for the application. In addition, a sign-out request is sent to the STS:

If you aren’t using the FederatedPassiveSignInStatus control, you can directly call WSFederationAuthenticationModule.SignOut to trigger a redirect to the STS with the sign-out request.

Single sign-out implies that the user is signed out of all applications she signed into with her federated identity. If the STS supports this, it should hold a list of RP applications the user logged in to during her session, and issue a clean-up request to each RP when federated sign-out is requested:

In more complex scenarios, the same clean-up request should be sent to any other STS involved in the federated session. To that end, the STS would have to have prior knowledge of the clean-up URI for each RP and STS. To support single sign-out, your RPs should be able to process these clean-up requests. Both the FAM and the FederatedPassiveSignInStatus control support this. If you’re using the FAM, the clean-up request can be posted to any URI at the RP and the FAM will process the request and clean up any session cookies. If you’re using the FederatedPassiveSignInStatus control, the clean-up request must be posted to a page that contains the control.

In fact, the WS-Federation specification does not detail how to implement single sign-out and clean-up behavior beyond the recommended query strings and flow of communication. It’s not easy to guarantee single sign-out will be effective across all federation partners as a result—but if you own the environment and want to achieve this goal, it’s indeed possible.

Michele Leroux Bustamante is chief architect at IDesign (idesign.net) and chief security architect at BiTKOO (bitkoo.com). She’s also a Microsoft regional director for San Diego and a Microsoft MVP for Connected Systems.

Thanks to the following technical expert for reviewing this article: Govind Ramanathan

Авторизация и аутентификация 3.0

Авторизация и аутентификация — первое, что требуется наладить практически во всех веб-приложениях, а значит, от этого будет отталкиваться и весь остальной функционал разрабатываемой системы. Уделить этому особое внимание не будет лишним. Данная статья посвящена встроенной системе авторизации и аутентификации в ASP.NET Core Identity, также называемой Identity 3.0.

Введение

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

Идентификация — процесс распознавания субъекта (пользователя, программы, процесса) на основе его идентификатора (имени, логина, номера телефона). Если предоставленный идентификатор существует в системе, идентификация прошла успешно, переходим к аутентификации.

Аутентификация — процедура проверки подлинности. Пользователь, предоставивший логин, должен подтвердить, что он тот, за кого себя принимает, например, с помощью пароля.

И третий этап — авторизация — заключается в проверке прав доступа аутентифицированного субъекта к ресурсу. Субъект считается авторизованным, если ему предоставлены соответствующие права доступа к объектам системы.

Начало

Вся эта функциональность уже реализована для ASP.NET Core — проект с открытым исходным кодом под названием Identity 3.0. Для настройки окружения вам понадобится установить:

  • Visual Studio 2015;
  • Update 3 для VS 2015;
  • .NET Core tools for Visual Studio.

Инструкцию по установке и ссылки можно найти здесь.


Для включения функционала Identity создадим проект ASP.NET Core Web Application по шаблону Web Application и в качестве типа аутентификации выберем Individual User Accounts.

В проект будет добавлен пакет Microsoft.AspNetCore.Identity.EntityFrameworkCore, который будет сохранять данные и схемы в SQL Server для Entity Framework Core.

Также этот пакет можно добавить через NuGet Package Manager.

Или же дописав соответствующие зависимости в файле project.json в узлах dependencies и tools.

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

Как это работает

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

В ASP.NET Core за настройку обработки запросов отвечает метод Configure класса Startup. При создании проекта с использованием шаблона по умолчанию в этот метод добавится строка app.UseIdentity () ; отвечающая за аутентификацию для потока запросов, основанную на куки.

Также в метод ConfigureServices этого же класса Startup будут добавлены Identity сервисы.

Это позволит использовать их в приложении с помощью встроенной системы внедрения зависимостей.

Теперь при обработке каждого запроса будет проводиться аутентификация пользователя. А авторизацию будет контролировать атрибут Authorize, который можно добавить перед контроллером и отдельным методом в MVC фреймворке.

ASP.NET Core был сильно изменен по сравнению с прошлыми версиями, не остался в стороне и Identity 3.0. Структура БД для Identity 3.0 имеет следующий вид:

Появились две новые таблицы: AspNetRoleClaims и AspNetUserTokens. Пользователи и роли, как и ранее, представлены классами IdentityUser и IdentityRole соответственно. Но теперь они не наследуются от интерфейсов для пользователей и ролей, что очень удобно. Также появились новые инструменты авторизации — политики.

Политика — это одно или несколько требований, необходимых пройти пользователю для авторизации.

Пример

Пусть для доступа к некоторому ресурсу в приложении пользователь должен иметь российское гражданство. Для начала зарегистрируем политику RussianСitizenship в ConfigureService файла startup.cs:

Для регистрации политики мы использовали RussianСitizenshipRequirement в качестве авторизационного требования — параметры данных, которые использует политика для оценки текущего пользователя. В нашем случае есть лишь один параметр — гражданство. Для создания требования нужно реализовать интерфейс IAuthorizationRequirement:

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

Добавим в HomeController метод RussianPage () c атрибутом Authorize:

Готово, доступ к этому методу получат лишь пользователи, удовлетворяющие требованиям данной политики.

Выводы

Это была обзорная статья, из которой видно, что Identity 3.0 является мощным инструментом, , который поддерживает:

  • авторизацию на основе ролей,
  • Claim-Based авторизацию,
  • аутентификацию через соцсети,
  • двухфакторную аутентификацию с подтверждением по смс или по электронной почте и др.

Для большинства сайтов этого достаточно для полноценной работы.

В следующей статье я постараюсь немного кастомизировать Identity и адаптировать его для использования в приложении с многослойной архитектурой.

Аутентификация и авторизация пользователей в ASP.NET MVC

Каков наилучший метод авторизации и аутентификации пользователя в ASP.NET MVC?

Я вижу, что есть действительно два подхода:

  • Использовать встроенную систему авторизации ASP.NET.
  • Используйте настраиваемую систему с моими собственными таблицами User, Permission, UserGroup и т.д.

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

На самом деле существует третий подход. Функция членства asp.net основана на модели поставщика. Вы можете написать пользовательский поставщик, таким образом, сможете предоставить свою собственную реализацию для хранения данных, но сохраняя большую часть преимуществ членства asp.net.

Некоторые статьи по теме:

Пойдите с обычаем. MembershipProvider слишком тяжел для моих вкусов. Да, возможно реализовать его в упрощенном виде, но затем вы получите действительно плохой запах NotSupportedException или NotImplementedException.

С полностью настраиваемой реализацией вы все равно можете использовать IPrincipal, IIdentity и FormsAuth. И действительно, насколько сложно сделать свою собственную страницу входа в систему и т.д.

Самый простой способ — использовать имена пользователей asp.net в качестве имен ролей. Вы можете написать свой собственный атрибут authorizarion для авторизации:

Код должен обрабатывать AuthorizeCore для возврата true, если пользователь запустил сеанс, а HandleUnauthorizedRequest перенаправляет пользователя на страницу входа (необязательно, вы можете прикрепить возвращаемый URL-адрес).

В методах контроллера, которым требуется авторизация, установите для них атрибут:

Также установите метод авторизации в «Формы» в веб-конфигурации.

В контроллере, когда пользователь вводит свое имя пользователя и пароль, установите cookie проверки подлинности форм в TRUE (FormsAuthentication.SetAuthCookie( «registereduser», true)), сигнализируя имя пользователя (зарегистрированный пользователь в примере) для аутентификации, Затем пользователь подписывается, сообщает ASP.NET, чтобы он вызывал FormsAuthentication.SignOut().

Используйте модель для хранения пользовательских данных.

Вид (который представляет тип SessionModel):

Используйте представление для получения данных. В этом примере есть скрытое поле для хранения возвращаемого URL

Надеюсь, это поможет (мне пришлось перевести код, поэтому я не уверен, что он на 100% прав).

authentication — Аутентификация пользователя с помощью Restful asp.net Web api и защита API

Я участвую в разработке веб-API asp.net с интерфейсом frontularJS. Я проводил много исследований об этом примерно неделю. Я читал о oauth 2, owin и других. Но теперь это смущает, что лучше.

У меня есть пара вопросов и надеюсь, что вы, ребята, можете мне помочь.

1) В моем приложении — только зарегистрированный пользователь сможет иметь доступ к приложению через вход в систему с помощью электронной почты и пароля. Может ли кто-нибудь указать мне хороший ресурс или статью о том, как создать хорошую регистрацию и аутентификацию входа в систему с помощью API. Это достаточно безопасно, так как я собираю данные пользователя и сохраняю их.

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

Обратите внимание, что это не дублирующий вопрос, который я прошел через большую часть сообщения в stackoverflow и спрашивал об этом после того, как я не смог найти ответ.

Любое предложение или помощь по этому поводу приветствуются.

Спасибо за все ваши усилия по этой теме

    3 2
  • 18 май 2020 2020-05-18 10:13:10
  • GeekOnGadgets

2 ответа

Vs2013 шаблона проекта webapplication поставляется с хорошей настройкой owin. Я предлагаю изучить, что

  • 18 май 2020 2020-05-18 10:13:12
  • Ibrahim ben Salah

Вы можете использовать аутентификацию на основе токенов, используя Asp.Net Web API 2, OWIN, Identity Asp.Net и AngularJS.

API-интерфейс Asp.Net Web теперь полностью поддерживает OWIN. Катана — это реализация OWIN в Microsoft Outlook.

Asp.Net Web API теперь поддерживает авторизацию с использованием OAuth 2.0. OAuth становится возможной благодаря компонентам Microsoft OWIN.

Я смущен словом Identity, OWIN, OAuth. вот краткий обзор их.

Идентификация Asp.Net разработана для преодоления проблем системой членства asp.net. Asp.Net Identity позволяет нам использовать разные хранилища (хранилище таблиц, нет SQL) и позволяет нам использовать внешние поставщики удостоверений, поскольку использует OWIN.

OWIN — это разрыв жесткой связи b/w Asp.Net и IIS. OWIN — это просто спецификация. Katana — это реализация Microsoft OWIN. OWIN находится в конвейере запросов HTTP. OWIN-конвейер имеет компоненты промежуточного программного обеспечения, где мы можем упомянуть внешние механизмы входа.

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

Примечание: Здесь Asp.Net Identity не имеет ничего общего с OWIN, OAuth и наоборот. Это три отдельных понятия. Идентификация Asp.Net — это реализация Microsoft. OWIN, OAuth открыты стандартные понятия. Поскольку Microsoft внедрила OWIN, OAuth стала возможной.

Таким образом, Web API 2 использует токен-маркер OAuth вместо файлов cookie для проверки подлинности, что более корректно в мире веб-API. Поскольку он позволяет использовать множество конечных пользовательских устройств, таких как мобильные устройства.

В вашем случае вы можете использовать шаблоны по умолчанию, представленные в visual studio 2013.
1. Создайте новый проект и выберите веб-приложение Asp.Net.
2. Выберите веб-API или шаблон SPA.
3. Измените аутентификацию и выберите отдельные учетные записи пользователей.
4. Нажмите «ОК».

Теперь все настроено по умолчанию, чтобы использовать OWIN, Identity Asp.Net, OAuth. Из-за того, что мы используем аутентификацию на основе токенов, вы можете обнаружить, что в Account Controller нет метода входа в систему.

  • Чтобы зарегистрировать пользователей, используйте метод Register, доступный в AccountController
  • Для входа в систему вам необходимо отправить данные в следующем формате: http://example.com/token (который можно настроить в StartUp.Auth.cs)
    grant_type = пароль & имя пользователя = Alice & пароль = password123
  • После входа в систему мы получаем токен-носитель, который нам нужно отправить с заголовком авторизации с каждым запросом на доступ к защищенному ресурсу.

Поскольку вы используете потрясающую инфраструктуру frontend Framework AngularJs, вы можете сохранить токен-носитель в локальном хранилище, и вы можете написать службу перехватчика http, которая позаботится о передаче маркера-носителя с каждым запросом.

Здесь регистрация пользователя выполняется по идентификатору Asp.Net, где по умолчанию пользователь OAuthAuthorizationServer по-прежнему находится в папке «Поставщики».

Носильщики-носители, которые мы получаем, относятся не к конкретному клиенту, поэтому любой может их перехватить. Поэтому используйте их только через SSL.

Аутентификация пользователей с помощью ASP

Аутентификация пользователей с помощью ASP

В этой статье будет рассказано, как зарегистрированным пользователям разрешить доступ к некой секретной asp странице, а посторонним нет.

Постановка задачи: Есть база данных Access 97, в которой хранятся имена зарегистрированных пользователей и их пароли, и есть некая секретная страница, доступ к которой должны иметь только пользователи, занесенные в БД. Пароли в БД требуется хранить в зашифрованном виде. Преимущество такого подхода в том, что поля базы данных, содержащие пароли, не содержат реальных значений и их нельзя использовать при входе в систему.

Для работы нам понадобится ActiveX компонент Ecrypt, который Вы можете взять на этом сайте в разделе ActiveX.

Движемся по шагам:

1. Создайте БД в Access. Имя таблицы — TUSERS. Описание полей:

n_id — Счетчик (Primary Key)

Затем создайте DSN для этой БД. При работе с WindowsNT (2000) необходимо создать System DSN, а при работе с Windows95-98 можно создать и User DSN. Дайте DSN имя reg.

2. Напишем ActiveX DLL Auth на Visual Basic 6, которая будет выполнять основную работу. Запустите Visual Basic 6 и в окне New Project выберем ActiveX DLL. Переименуем имя проекта на Auth, а имя класса на Security. Теперь надо подключить необходимые библиотеки: выбираем Project ->References.

Подключаем библиотеки Microsoft ActiveX Data Objects 2.1 Library и ECrypt 1.0 Type Library (см. выше).

3. Далее набираем следующий код:

Private cn As ADODB.Connection

Private rs As ADODB.Recordset

Private sName As String ‘Имя пользователя

Private sPasswd As String ‘Пароль

Private sError As String

Private sResult As Integer ‘Результат

Public Property Get Result() As Integer

Public Property Let InitName(ByVal Name As String)

Public Property Let InitPassword(ByVal Passwd As String)

Private Sub Class_Initialize()

Set cn = New ADODB.Connection

cn.Open «DSN=reg» ‘Установим соединение

Set rs = New ADODB.Recordset

Private Sub Class_Terminate()

Set rs = Nothing

Set cn = Nothing

Public Sub Register()

On Error GoTo Er

rs.Open «SELECT N_ , cn, 1

‘Если пользователь с таким именем уже есть, то

Илон Маск рекомендует:  ob_start - включает буферизацию вывода
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL