Использование веб-сервисов при авторизации пользователей Любое применение технологии или какого-либо технологического приема имеет под собой определенные причины. Главная причина – это решение проблемы. Проблема это первое, что возникает, и на помощь приходит технология, призванная решить проблему. Будь то разработка приложения или проектирование и разработка какого-то устройства – технология это решение. Возьмем, к примеру, постройку моста через реку. Первое, что мы имеем это река, которую требуется пересечь для того, чтобы соединить населенные пункты или дороги. Далее приходит решение в виде моста, по которому затем можно свободно передвигаться. И здесь технология это решение проблемы, потому что без технологии возведения мостов невозможно построить мост. Попробуем рассмотреть нашу проблему, которую должно решить использование веб-сервисов для авторизации пользователей. Для чего это нужно? Какие есть возможные решения? Какие технологии можно использовать при решении данной проблемы? Ответы на эти и другие вопросы я постараюсь изложить ниже. Очень часто в веб-приложениях используются системы, позволяющие распределить между пользователями определенные роли, а вместе с этим доступную информацию, права, а также обязанности пользователей. Это позволяет снизить нагрузку на пользователя, оградить от ненужных действий и проблем. К примеру, имеется некая система, которая призвана автоматизировать процесс обучения. Здесь есть студенты и преподаватели. Что должен делать и знать преподаватель? Преподаватель должен иметь возможность просмотреть список своих студентов и проконтролировать процесс выполнения ими заданий. Кроме этого преподавателю необходима возможность оценить выполненные студентами задания и при желании прокомментировать различные моменты, касающиеся выполнения. Какие возможности должны предоставляться студенту? Студент должен знать список своих заданий и иметь возможность донести до преподавателя о том, что он сдал задание на проверку. Получается, что возможности и обязанности студента и преподавателя различны. Как разделить студентов и преподавателей – создать соответствующие роли и разграничить доступ. Далее – у каждого преподавателя свой список студентов и свои задания, которые он должен проверить и оценить. Для этого в системе создаются пользователи, каждому пользователю при этом непременно отводится роль. Как правило, каждый пользователь идентифицируется логином и паролем. Именно роль определяет, кто есть такой пользователь и какие возможности ему необходимо предоставить. Для реализации этого необходимо наличие системы, которая бы отвечала за авторизацию пользователей. Пользователь вводит логин и пароль и отправляет на проверку системе. Система получает логин и пароль от пользователя и принимает решение о том, впустить пользователя или нет. Естественно, пароль для доступа должен быть известен только этому пользователю, чтобы никакой другой недобросовестный пользователь не смог воспользоваться ими и войти от имени первого пользователя. Изложенные выше принципы функционирования не являются секретом и известны каждому, кто хоть раз пользовался электронной почтой или заходил в сеть, например, какой-то организации или же учебного учреждения. А что делать, если приложений, для которых требуется логин и пароль, несколько. Причем для каждого приложения свой набор логин/пароль? Получается дублирование функций – у каждой системы или приложения есть блок, отвечающий за авторизацию и хранящий список пользователей системы. Вот ключевой момент. А что если взять и вынести этот блок в отдельную систему или приложение. Тогда дублирования не будет. К сожалению, на словах всё просто, а вот на деле оказывается куда сложнее. И здесь есть несколько проблем. Во-первых, приложения пишутся на разных языках и платформах, и выбор какой-то конкретной платформы означал бы жесткую привязку к ней. Следовательно, необходимо какое-то универсальное кроссплатформенное решение, которое позволяло бы работать с различными языками и платформами. Во-вторых, система должна позволять воспользоваться своими возможностями удаленно, то есть не только через локальную сеть, а еще, например и через VPN. На помощь в решении проблемы приходят веб-сервисы. Давайте посмотрим, что же такое веб-сервисы и как они решают поставленную задачу. Веб-служба, веб-сервис — программная система, идентифицируемая строкой URI, чьи общедоступные интерфейсы определены на языке XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью интернет-протоколов. Веб-служба является единицей модульности при использовании сервисно-ориентированной архитектуры приложения. Веб-сервисы позволяют решить проблему нескольких платформ и языков, благодаря тому, что используют стандартный протокол обмена сообщениями SOAP. Это позволяет равноценно использовать его как из приложений, написанных, к примеру, на Java, так и на C#. В настоящее время имеется достаточное количество инструментов, как платных, так и открытых для любого разработчика, облегчающих написание как самих веб-сервисов, так и приложений-клиентов, использующих возможности веб-сервисов. Разработчику нет необходимости погружаться во все премудрости и тонкости функционирования веб-сервисов, однако, в редких случаях это бывает необходимо. Что касается использования веб-сервисов удаленно, то это также возможно. Даже больше, изначально они для этого и предусмотрены – для удаленного использования их функционала. Стоит также сказать, что есть несколько реализаций данной технологии. Некоторые их них тяжеловесны и требуют отдельного сервера, потому что работают в составе более сложных систем таких как ESB (Enterprise System Bus). Другие наоборот – очень лёгкие и позволяют создавать веб-сервисы путем реализации простых интерфейсов и включения в приложения небольшой библиотеки, размер которой составляет несколько мегабайт. Если вы Java разработчик, то достаточно продуктивной оказывается связка Axis2, Tomcat и Eclipse. Данная связка использовалась автором при решении подобной проблемы и является на его взгляд, пожалуй, самым правильным выбором. Для наглядности рассмотрим общую схему построения системы и её использования. Естественно, сердцем системы является веб-сервис или веб-служба. Веб-сервис предоставляет унифицированный интерфейс для того, чтобы внешние приложения или какие-либо другие клиенты могли обратиться к нашему веб-сервису и получить необходимую информацию от него. С точки зрения разработчика веб-сервиса процесс разработки будет очень похож на разработку утилитного класса с необходимыми методами за тем лишь исключением, что после написания нужно будет, при использовании специальных инструментов, сгенерировать низкоуровневые классы, которые будут обеспечивать передачу данных и удовлетворять спецификации вебсервисов. Написание этих классов возможно и вручную, но с помощью инструментов, о которых говорилось ранее, это занимает намного меньше времени и позволяет разработчику сосредоточиться на основной задаче. Веб-сервис взаимодействует с хранилищем пользователей, который в самом простом случае представляет собой обычный список пользователей с краткой информацией о каждом, а также логинами и паролями. Для повышения уровня безопасности пароли могут храниться в зашифрованном виде. Возможны и другие приемы для повышения безопасности и устойчивости веб-сервиса. Кроме этого хранилище может содержать такую информацию, как роль пользователя и его права. В качестве хранилища может использоваться база данных. Подключение к базе данных веб-сервис будет осуществлять через драйвер, разработанный специально для определенной БД. Хорошим бы решением было решение, которое позволило бы веб-сервису не привязываться к определенной базе данных, то есть к определенному производителю, а быть независимым от него. К примеру, разрабатывая веб-сервис на Java, разработчик имеет возможность реализовать это посредством использования инструмента Hibernate. Hibernate берет на себя все трудности по взаимодействию с базой данных, а снаружи предоставляет удобный и достаточно мощный интерфейс. Hibernate позволяет конфигурировать себя с помощью специальных конфигурационных XML файлов. Это дает возможность разработчику приложения переподключиться к другой базе данных без переписывания исходного кода приложения и дальнейшей его перекомпиляции. В качестве хранилища может использоваться и Active Directory, который специально для этого и предназначен. Возможно, что хранилище будет представлять собой какое-то кастомизированное и разработанное на заказ ранее приложение, играет большую роль в информационной инфраструктуре учреждения и от которого невозможно отказаться в силу определенных причин.