Single Sign-On в интеграционных проектах IIS и Java

Описание проблемы

Для одного из наших проектов нужно было разработать несколько новых компонентов для существующего решения - 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 и я написал свой, руководствуясь вот этой документацией.