Описание проблемы
Для одного из наших проектов нужно было разработать несколько новых компонентов для существующего решения - web-портала.
Портал написан на ASP (даже не ASP.NET) с MS SQL Server 2000 и до сих пор поддерживается - периодически выходят новые версии.
Одним из требований заказчика была поддержка функции Single Sign-On между существующими и разрабатываемыми компонентами.
В этом посте я хочу рассказать о тем чем я руководствовался при разработке архитектуры решения и как в итоге был реализован механизм SSO. Забегая вперед, отмечу, что данное решение может подойти для интеграционных проектов, в которых есть необходимость организовать SSO между существующими web-приложениями (ASP/PHP) и вновь разрабатываемыми на Java EE компонентами.
Выбор инструмента
Платформа
Из соображений лицензионной чистоты и снижения лицензионных отчислений было принято решение разрабатывать новые компоненты с использованием стека Open Source решений и, в частности, на платформе Java. Если кому-то интересно почему Java - обращайтесь в комментарии - это не тема для данного поста :)
В последнее время мне очень нравится Open Source линейка OpenX, поддерживаемая открытым сообществом dev.java.net во главе с Sun Microsystems. Особенно привлекает NetBeans, который является по-настоящему мощной и, поправьте если я не прав, первой в мире и единственной бесплатной Open Source RAD для разработки Java-приложений (включая Java ME/SE/EE), чем не может похвастаться ни одна другая IDE (включая Eclipse и IDEA).
Eclipse, как IDE, мне нравится больше NetBeans, особенно JDT и его Java Editor, который в разы превосходит NetBeans по функциональности. Но Eclipse очень сильно проигрывает NetBeans в плане RAD. Многие знают, что на базе Eclipse есть разные реализации RAD (от IBM, ориентированная на линейку WebSphere; от SAP для NetWeaver), но все они платные и, поэтому, не идут ни в какое сравнение с NetBeans.
Что мне особенно нравится у NetBeans - это набор его WYSIWYG-редакторов GUI и различные мастера конфигураций, которые очень сильно сокращают время разработки. Именно этим мы и хотели воспользоваться.
Single Sign-On
На тот момент я был знаком лишь с одним фреймворком, поддерживающим SSO - это JOSSO.
JOSSO позволяет организовать SSO между веб-приложениями, физически расположенными в рамках одного сервера приложений. После того, как пользователь прошел аутентификацию в одном из "партнерских" приложений JOSSO, серверный агент JOSSO запоминает его логин и членство в ролях. При последующих обращениях пользователя к партнерским приложениям, агент автоматически пытается аутентифицировать пользователя, избавляя его от повторного ввода пароля. Эта схема работает на Tomcat. Существуют агенты и для других серверов приложений.
Но именно из-за того, что JOSSO не поддерживает Glassfish, я побоялся остановить на нем свой выбор - Glassfish еще слишком молодой и не имеет большой поддержки со стороны Open Source сообщества.
В линейке OpenX есть продукт Open SSO, поддерживающий Glassfish, но реализованного агента для IIS у этого продукта не было.
У JOSSO есть агент для IIS, но, как потом выяснилось, и JOSSO, в дополнение к вышесказанному, и Open SSO под Single Sign-On понимают немного другую схему аутентификации - схему основанную на токенах.
В этой схеме приложение, проводя процедуру аутентификации пользователя, получает у Identity Provider'а токен - сессионный ключ. Этот ключ может передаваться между партнерскими приложениями, например, через Cookies. В такой схеме, имея сессионный токен пользователя, приложение самостоятельно может запросить у централизованного сервиса права пользователя и провести процедуру авторизации.
В нашем случае это означало бы полностью переписать функции аутентификации и авторизации портала по новой схеме, что было бы крайне нежелательно, так как требовало бы больших усилий при разработке и применении новых обновлений портала. Кроме того ASP и MS SQL Server 2000 - это устаревшие технологии и никаких новых стратегических компетенций мы бы не получили с этого проекта.
Исходя из всего вышесказанного было принято решение в качестве сервера приложений выбрать Apache Tomcat - наиболее распространенный и широко поддерживаемый открытым сообществом Open Source сервер приложений (я знаю, что там только web-контейнер, нам больше не надо :). Решение было принято из расчета на то, что если и можно сделать SSO на Java, то на Tomcat это решение заработало бы с вероятностью 99.999%.
Описание решения
В основе найденного решения лежит The Apache Tomcat Connector - "мостик", который используется для запуска Tomcat за web-серверами, такими как Apache HTTPD и Microsoft IIS.
В этой схеме весь HTTP-трафик пользователя проходит через web-сервер (в нашем случае IIS) и передается Tomcat'у, который обрабатывает запрос и возвращает результат.
Это возможно за счет ISAPI-фильтра, который отвечает за перенаправление всех HTTP-запросов. Такое перенаправление возможно за счет поддержки Tomcat'ом бинарного протокола AJP13, по которому происходит эта передача. Возможно другие сервера также поддерживают AJP13 и для них можно организовать аналогичную схему - я не пробовал, но если у кого-то получится, большая просьба отметиться в комментариях.
Особенности решения
Аутентификация пользователей в портале ASP осуществляется путем сохранения информации об имени пользователя и его членства в ролях, которая сохраняется в объекте ASP Session (сессия приложения).
Если бы аутентификация осуществлялась стандартными средствами, например, HTTP Basic Authentication, то в Java EE приложении имя пользователя можно было бы получить через интерфейс
HttpServletRequest.getRemoteUser(...).Но так как сессия лежит за границами протокола HTTP, из Java непосредственно нельзя получить к ней доступ. Однако в HTTP-заголовках передаются Cookies, в которых сохраняются сессионные ключи приложений (
JSESSIONID, PHPSESSIONID, ASPSESSIONIDxxx). Благодаря этому мы можем обратиться к приложению по протоколу HTTP, передав сессионный ключ и попасть в контекст нужной сессии, где нам будет доступна вся необходимая информация.
Реализация
Для этого в партнерское приложение достаточно добавить страницу
sessioninfo.asp следующего содержания:UserID=<%=Session("UserID")%>
UserType=<%=Session("UserType")%>
Соответственно, из Java приложения, чтобы получить информацию о пользователе (в данном случае это его идентификатор и тип, на основании которых можно сделать запрос к БД и получить всю дополнительную информацию, если это необходимо), достаточно обратиться по адресу, например,
http://localhost/asp-portal/sessioninfo.asp и рас-parse-ить результат:01: <%@ page contentType="text/html; charset=iso-8859-1" language="java" %>
02: <%@ page import="java.net.*"%>
03: <%@ page import="java.io.*"%>
04: <%@ page import="java.util.Properties"%>
05:
06: <%
07: Cookie[] cookies = request.getCookies();
08:
09: String value = "";
10:
11: for (int i = 0; i < cookies.length; i++) {
12: Cookie cookie = cookies[i];
13: value += cookie.getName() + "=" + cookie.getValue() + ";";
14: }
15:
16: URL url = new URL("http://localhost/asp-portal/sessioninfo.asp");
17:
18: URLConnection c = url.openConnection();
19:
20: c.setRequestProperty("Cookie", value);
21:
22: InputStreamReader in = new InputStreamReader(c.getInputStream());
23:
24: Properties p = new Properties();
25: p.load(in);
26:
27: in.close();
28: %>
При таком подходе на каждый запрос к Java-компоненту идет обратный дополнительный запрос к ASP-порталу. Вопрос производительности для нас не был критичным, но в несколько миллисекунд обратный запрос укладывался.
Остается отметить, что чтобы браузер передавал Cookies Java-приложению они должны быть в одном домене (URL) с порталом. Для других проектов это может быть ограничением, но в нашем случае это было скорее требованием.
Источники информации
Инструкцию по настройке Tomcat и IIS можно найти здесь: How To Configure IIS 6.0 and Tomcat with the JK 1.2 Connector. Мне пришлось немного изменить описанный сценарий, моя установка отказалась принимать приведенный там в примере файл
workers.properties и я написал свой, руководствуясь вот этой документацией.
