Разработка системы аутентификации "Контекстум-ID"

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

С другой стороны, развивающаяся компания-поставщик некоторых услуг при помощи тех или иных информационных технологий также может поставить своих потенциальных клиентов в неудобное для них положение в связи с необходимостью вникать в каждую из систем в отдельности. Ситуация усложняется предъявляемыми требованиями к безопасности при использовании большинства современных систем, будь то локальные или удаленные приложения или системы. В частности, одним из неудобств как для сотрудников, так и для клиентов развивающей информационные технологии и услуги, завязанные на информационных технологиях компании, является разрозненность существующих и создаваемых новых систем. Для решения одного из аспектов такой проблемы существует и широко применяется довольно долгое время технология единого входа, направленная на решение. Технология единого (однократного) входа (англ. «Single Sign-On», «SSO») - технология доступа к различным приложениям посредством однократной процедуры аутентификации [6]

Данная технология призвана решить ряд задач, таких как:

устранение необходимости создания системы регистрации, идентификации и аутентификации пользователя для каждой системы в отдельности;

задачу обеспечения безопасности при использовании систем компании и, наконец, позволяет объединить ряд систем при помощи единого интерфейса входа, давая понять пользователям, что они находятся в рамках взаимосвязанной системы;

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

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

В настоящей дипломной работе будет рассмотрена компания-поставщик информационной технологии «Контекстум», а также ряд сервисов, предоставляемых в рамках данной технологии и в пределах других интернет-сервисов консорциума «Контекстум».

Приведем список существующих Интернет-сервисов:

национальный цифровой ресурс «РУКОНТ» - межотраслевая научная библиотека на базе информационной технологии «КОНТЕКСТУМ». Здесь размещен цифровой контент различного рода: книги, периодические издания и отдельные статьи, а также аудио-, видео-, мультимедиа, софт и многое другое. Основная задача - помочь Вам решить научные и образовательные задачи, скрасить досуг[7];

ряд сервисов Руконтекст [8], среди которых:

сервис поиска текстовых заимствований. Обеспечивает поиск фрагментов проверяемых документов в ранее опубликованных произведениях.Сервис предназначен для определения оригинальности проверяемого текста и выявления текстовых заимствований из ранее опубликованных произведений;

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

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

русскоязычный архив электронных статей периодических изданий. Главная цель проекта - обеспечение доступа к полным текстам статей российских научных журналов, в том числе и к тем, которые не входят в существующие ныне электронные базы данных. [9];

центральный коллектор библиотек "БИБКОМ". Комплектует библиотеки книгами, периодикой, мультимедиа, бибтехникой. С 2013 года предлагается подписка на электронные полнотекстовые коллекции в "Национальном цифровом ресурсе "РУКОНТ"[10];

ООО «Агентство «Книга-Сервис» и ОАО «Агентство по распространению зарубежных изданий», являющиеся соучредителями федерального подписного каталога «Объединенный каталог «Пресса России» [11]. Основным видом деятельности являются услуги по организации подписки на различные периодические издания - газеты и журналы, в том числе организация подписки через Интернет.

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

Целью разработки системы аутентификации «Контекстум-ID» является разделение процессов аутентификации и авторизации пользователей на интернет-сервисах консорциума «Контекстум». В том числе: сайт НЦР «РУКОНТ», сервисы проекта СВПОН «РУКОНТ», сервис проекта «РУАЕСТ», сервис центрального коллектора библиотек «БИБКОМ», сервис распространения печатных изданий агентства «Книга-Сервис» (далее Сервисы).

Указанное разделение процессов аутентификации и авторизации должно обеспечить возможность формирования системы «единого входа» (Single Sign-On, SSO) для пользователей Сервисов и облегчить пользование Сервисами.

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

В рамках данной задачи должны быть решены следующие подзадачи:

агрегирование всех существующих пользователей с их идентификационными и аутентификационными данными в единый список и создание единого хранилища для него;

создание универсальной системы идентификации и аутентификации пользователей;

создание методов и средств для обеспечения связи между Сервисом и системой единой идентификации и аутентификации;

проверка работоспособности созданной системы и ее внедрение на одном из Сервисов.

1. Способы аутентификации и их применимость относительно системы

аутентификация сервис триггер репликация

Система представляет собой одностраничное приложение с использованием фреймворка Angular-JS для создания front-end части системы, призванное решить следующие задачи [12]:

отделение DOM-манипуляции от логики приложения, что улучшает тестируемость кода;

отношение к тестированию как к важной части разработки. Сложность тестирования напрямую зависит от структурированности кода;

разделение клиентской и серверной стороны, что позволяет вести разработку параллельно;

проведение разработчика через весь путь создания приложения: от проектирования пользовательского интерфейса, через написание бизнес-логики, к тестированию.

Angular придерживается MVC-шаблона проектирования и поощряет слабую связь между представлением, данными и логикой компонентов. Используя внедрение зависимости, Angular переносит на клиентскую сторону такие классические серверные службы, как видозависимые контроллеры. Следовательно, уменьшается нагрузка на сервер и веб-приложение становится легче.

Как уже было отмечено выше, особенностью системы является разделение клиентской и серверной стороны приложения, где серверная сторона отвечает на запросы клиента и реализует всю логику системы. Одним из наиболее часто практикуемых решений в области создания серверной части приложений является разработка так называемых RESTful сервисов. Отличительной особенностью данного архитектурного стиля является единый интерфейс между клиентом и сервером [13]. Такое разделение подразумевает отсутствие связи между клиентами и хранилищем данных. Это хранилище остаётся внутренним устройством сервера, таким образом переносимость клиентского кода увеличивается, что способствует упрощению сервера и его масштабируемости.

Для реализации RESTful подхода были выбраны технологии .NET фреймворка. ASP.NET Web API - это фреймворк для построения Web API над .NET фреймворком. Платформа веб-API ASP.NET позволяет с легкостью создавать службы HTTP для широкого диапазона клиентов, включая браузеры и мобильные устройства. Веб-API ASP.NET идеально подходит для разработки приложений RESTful на платформе .NET Framework.

1.2 Подходы к организации аутентификации и авторизации пользователя

Применительно к RESTful API как правило выделяют 6 способов аутентификации (их на самом деле больше):

Basic;

Digest;

Token;

Certificate;

Digital signature;

с применением ключей API (oAuth, oAuth 2.0).

Первый и второй способ используют для доверенных клиентов.

Ключи API используют для сторонних клиентов.

1.3 Basic-аутентификация

Метод базовой аутентификации - наиболее простой при разработке.

Недостатки:

- наиболее низкий уровень защиты, прописанный в опциях протоколов. Чаще всего используется в течение разработки, но не рекомендуется для использования в Production [14].

Схема действия: в заголовке посылается логин и пароль, закодированные в Base64. Использование SSL/TLS становится обязательным. Схема действия basic-аутентификации представлена на рисунке 1.1.

Пример использования: JIRA REST API - Basic authentication.

Подготовка данных: base64decode(<username>:<password>).

Таблица 1.1 - Пример запроса для basic-аутентификации

Рисунок 1.1 - Схема действия Basic-аутентификации

1.4 Digest-аутентификация

Недостатки:

для каждого запроса необходимо 2 запроса, что делает Digest-авторизацию более медленной: вызов любого нового метода предполагает получение нового значения nonce (случайно сгенерированное на сервере значение, предоставляется и используется единожды),

уязвима к атаке man-in-the-middle, атака на воспроизведение,

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

Схема действия (для случая перехода на страницу, требующей авторизации):

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

сервер отвечает 401 «клиент-ошибка», предоставляя область аутентификации и случайно сгенерированное, одноразовое значение;

на данном шаге клиент будет предоставлять область аутентификации (как правило, описание компьютера или системы, осуществляющей доступ) пользователю и запросит имя пользователя и пароль. Пользователь может принять решение об отмене в этот момент;

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

в этом примере сервер принимает аутентификацию и страница возвращается. Если имя пользователя является недействительным и / или пароль неверный, сервер может вернуть код ответа «401» и клиент будет запрашивать их у пользователя еще раз [15].

Примечание: клиент может уже содержать имя пользователя и пароль, без необходимости запрашивать у пользователя, например, если они ранее были сохранены веб-браузером.

Использование SSL/TLS является обязательным.

Подготовка данных:

HA1 = MD5("Mufasa:testrealm@host.com:Circle Of Life")= 939e7578ed9e3c518a452acee763bce9

HA2 = MD5("GET:/dir/index.html")= 39aff3a2bab6126f332b942af96d3366

Response = MD5("939e7578ed9e3c518a452acee763bce9:\dcd98b7102dd2f0e8b11d0f600bfb0c093:\00000001:0a4f113b:auth:\39aff3a2bab6126f332b942af96d3366")= 6629fae49393a05397450978507c4ef1

Таблица 1.2 - Пример запроса не аутентифицированного пользователя без указания учетных данных

Таблица 1.3 - Ответ от сервиса для digest-аутентификации в случае неудачи авторизации

Таблица 1.4 - Запрос клиента для digest-аутентификации (имя пользователя «User1», пароль «Password1»)

Таблица 1.5 - Ответ сервера для digest-аутентификации в случае удачной авторизации (имя пользователя «User1», пароль «Password1»)

OAuth (oAuth2)

Принцип работы oAuth заключается в использовании временных токенов.

Недостатки:

сложнее в реализации,

является зависимым от состояния (аналогичен cookie - stateless),

уязвим к атакам man-in-the-middle, воспроизведения.

Схема действия:

Оправдывает свое использование для клиентов 3ей стороны: у них нет логина, пароля и разрешений аналогичных пользовательским, поэтому необходимо отдельно хранить все разрешения для независимых клиентов. Для этих целей разработчик получает ключ API (API key) - длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password, - а пользователи разрешают доступ к части их разрешений. Например: доступ на просмотр имени, почтового адреса и прочего[16].

После выдачи разрешений третьей стороне, ей выдается токен на доступ, по которому они получают доступ уже к пользовательским разрешениям. Схема действия по протоколу OAuth 2.0 представлена на рисунке 1.2.

Рисунок 1.2 - Схема действия Bearer-аутентификации

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

1.5 Пример использования: Amazon Web Services

Например, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Рисунок 1.3 - Пример применения аутентификации по ключу.

Таблица 1.6 - Запрос клиента (RFC 6749) для получения токена

Таблица 1.7 - Запрос клиента (RFC 6749) для получения авторизации по полученному токену

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант -- использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS [16].

Рисунок 1.4 - Пример аутентификации по ключу доступа, переданного в HTTP заголовке

Самый простой способ передачи таких данный (при условии использования SSL/TLS) - это рандомно созданный токен на доступ, который выставляется в поле username для HTTP Basic.

1.6 Аутентификация по Cookies

Схема действия:

В идеальном RESTful сервисе контроль за состояниями полностью производится на стороне клиента.

Для клиентов, помимо браузеров, COOKIES сложны в обработке.

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

- api смотрит на заголовок «Authorization», в случае не-браузерных клиентов именно туда будет помещена информация для авторизации

- если такой заголовок отсутсвует, то проверяется сессионная cookie для осуществления авторизации на стороне сервера.

Недостатки:

не отвечает требованиям RESTful сервиса в вопросе независимости от состояния,

уязвима к атакам man-in-the middle, воспроизведение,

на стороне сервера каким-то образом нужно хранить сессионную id, что противоречит REST-идеологии.

Таблица 1.6 - Запрос клиента (RFC 6749) для получения токена

1.7 Аутентификация по токенам и SSO

Такой способ аутентификации чаще всего применяется при построении распределенных систем, использующих единый сервис для входа (SSO), где одно приложение, выступающее в качестве Cервиса-поставщика (англ. «service provider», «relying party», «SP»), - в данной работе это один из описанных во введении Сервисов, - делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Такое приложение представляет собой сервис-поставщик идентификационных услуг. Сервис-поставщик идентификационных услуг (англ. «identity provider», ««identity assertion provider», «IdP») - решает следующие основные задачи:

предоставляет идентификаторы пользователей, взаимодействующих с системой;

предоставляет подтверждение того факта, что такой идентификатор известен сервису-поставщику;

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

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

Реализация этого способа заключается в том, что IdP-сервис предоставляет достоверные сведения о пользователе в виде токена, а SP-приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.

На общем уровне, весь процесс выглядит следующим образом:

клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.);

клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту;

клиент аутентифицируется в SP-приложении при помощи этого токена.

Рисунок 1.5 - Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer-схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же -- пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями IdP и SP.

Рисунок 1.6 - Пример аутентификации «пассивного» клиента посредством перенаправления запросов

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов -- OAuth, OpenID Connect, SAML, и WS-Federation.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

токен был выдан доверенным identity provider приложением (проверка поля issuer);

токен предназначается текущему SP-приложению (проверка поля audience);

срок действия токена еще не истек (проверка поля expiration date);

токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене[16].

Выбор способов аутентификации

Выбор способ аутентификации находится в зависимости от назначения API, а также основных типов клиентов, для которых предназначено данное API.

Назначением API может быть следующее:

основное назначение. Взаимодействие с front-end частью системы для выполнения основной бизнес-логики системы

вторичное. Использование методов, предоставляемых API, сторонними приложениями;

точка доступа для осуществления однократного входа пользователя в рамках использования нескольких систем ООО НЦР «РУКОНТ».

Основные типы клиентов можно подразделить на

браузерные;

не браузерные.

Отсюда можно сделать вывод о необходимости внедрения двух способов аутентификации.

аутентификация по cookie, являющаяся классическим решением, применяющимся для браузеров;

аутентификация по токену, являющаяся широко распространенным решением для RESTful сервисов.

О технологии

Web API применяет спецификацию Oath2, которая описывает механизм аутентификации на основе токенов. Конкретную реализацию этой спецификации представляют компоненты OWIN, благодаря которым и производит генерация токенов, их выдача клиенту и их дальнейшая валидация. Поэтому при создании приложения Web API нам не надо самим реализовывать сервер авторизации, все эти детали, а досточно взять готовый механизм, который предоставляет ASP.NET [17].

2. Реализация аутентификации и авторизации

2.1 Аутентификация по cookie

Для реализации метода входа в систему с дальнейшим присвоением пользователю аутентифкационной cookie была выбрана стандартная реализация, имплементированная в OWIN Middleware.

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

Для настройки аутентифицирующей cookie были выбраны следующие параметры:

срок действия cookie - 12 часов с момента аутентификации;

режим аутентификации - активный, что гарантирует создание пользовательской сущности как только получен запрос;

название cookie - rucontAPI.

Реализация аутентификации по cookie включает следующие два метода:

POST api/account/session - вход в систему;

DELETE api/account/session - выход из системы.

Блок-схемы алгоритмов аутентификации и выхода из учетной записи представлены на рисунках 2.1 и 2.2.

Рисунок 2.1 - Блок-схема алгоритма аутентификации пользователя по cookie

Рисунок 2.2- Блок-схема алгоритма аутентификации пользователя по cookie

Исходные коды методов представлены в приложении 1.

2.2 Аутентификация по токену

Авторизация на основе токенов состоит из нескольких компонентов:

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

веб-сервис, к ресурсу которого обращается клиент;

токен доступа (access token), наличие которого дает доступ к ресурсам веб-сервиса;

Bearer-токен - специальный вид токена доступа;

сервер авторизации, который выдает токены доступа клиенту.

Весь процесс аутентификации выглядит следующим образом, представленным на рисунке 2.3.

Рисунок 2.3 - Схема процесса аутентификации по токену

Пользователь вводит данные авторизации (логин, пароль) и нажимает на кнопку отправки;

клиент (веб-браузер) отправляет данные серверу авторизации;

сервер авторизации аутентифицирует пользователя и возвращает токен доступа;

для доступа к ресурсу веб-сервиса клиент добавляет в запрос ранее полученный токен доступа.

Хотя выше сервер авторизации и веб-сервис, но в реальности они могут быть объединены, как это и происходит в приложении Web API (рисунок 2.4).

Размещено на http://www.allbest.ru/

[Введите текст]

Рисунок 2.4 - Объединение сервера авторизации и веб-сервиса

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

Настройки аутентификации по токену имеют следующие параметры:

срок действия токена - 14 дней с момента аутентификаци;

режим аутентификации - пассивный.

Проектирование таблицы в базе данных Identity

Для обеспечения хранения информации о «сессиях» в базе данных Identity спроектируем дополнительную таблицу UserSession. Схема базы данных в части обеспечения хранения сессии пользователя представлена на рисунке 2.3

Рисунок 2.3 - Схема базы данных в части обеспечения хранения сессии пользователя

2.3 Реализация аутентификации по токену

Реализация аутентификации по cookie включает следующие два метода:

POST api/account/token - вход в систему;

DELETE api/account/token - выход из системы.

Блок-схемы алгоритмов аутентификации и выхода из учетной записи представлены на рисунках 2.5 и 2.6.

Рисунок 2.5 - Блок-схема алгоритма аутентификации пользователя по токену

Рисунок 2.6 - Блок-схема алгоритма аутентификации пользователя по токену

Исходные коды методов представлены в приложении 2.

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

3. Регистрация пользователя и управление паролем

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

Регистрация - POST api/account/register;

Смена пароля авторизованного пользователя - PUT api/account/password;

Запрос токена для сброса пароля неавторизованным пользователем DELETE api/account/password;

Сброс пароля по токену неавторизованным пользователем POST api/account/password?token=<token>&email=<email>.

3.1 Проверка работоспособности реализованных методов

Аутентификация по cookie

Запрос на аутентификацию по cookie

Рисунок 3.1 - Запрос на вход в систему по cookie

Таблица 3.1 - Ответ в случае успешного входа в систему

3.2 Вызов метода, требующего авторизации по cookie