Содержание


Единый вход на базе WebSEAL для телекоммуникационных шлюзов WAP 2.0/GPRS/3G

Comments

1 Основные компоненты и их взаимодействие

1.1 Архитектурное решение портала для мобильных телефонов

Телекоммуникационные шлюзы (i-mode, WAP 2.0/GPRS/3G) имеют свои собственные механизмы аутентификации пользователей. Это означает, что подлинность трафика HTTP, исходящего из этих шлюзов, должна быть уже проверена ранее. С другой стороны, портал для мобильных телефонов тоже имеет механизм аутентификации пользователей. Это становится проблемой, если мобильный портал вновь требует пароль от пользователей, пришедших из телекоммуникационных шлюзов. Этой проблемой нельзя пренебрегать, так как набирать имя пользователя и пароль на мобильном телефоне крайне неудобно. В этой статье мы предлагаем способ реализации единого входа (SSO) для решения этой проблемы. Предлагаемый способ основан на WebSEAL. Общая архитектура решения показана на рисунке 1.

Рисунок 1. Общая архитектура портала для мобильных телефонов
Общая архитектура портала для мобильных телефонов
Общая архитектура портала для мобильных телефонов

Здесь имеется три вида HTTP-трафика. Эти потоки трафика характеризуются следующим образом.

  1. HTTP-трафик из некоторых шлюзов WAP 2.0 уже аутентифицирован и содержит в заголовке HTTP номер мобильного телефона. WebSEAL будет доверять этим шлюзам, извлекая номер мобильного телефона из заголовка HTTP и используя его для автоматического входа на мобильный портал. На рисунке 1 этот поток трафика обозначен красной пунктирной линией.
  2. HTTP-трафик из шлюзов i-mode и некоторых шлюзов WAP 2.0 содержит номер мобильного телефона не в заголовке HTTP, а в других местах, например, в строке запроса URL, либо для извлечения номера мобильного телефона из запроса HTTP требуется предварительная обработка (например, преобразование шестнадцатеричных кодов ASCII в десятичную строку). Этот вид трафика должен проходить через модуль предварительной обработки заголовков HTTP (в этой статье приведен интеграционный плагин). Модуль извлекает номер мобильного телефона и добавляет его в заголовок HTTP, который WebSEAL затем использует для SSO. На рисунке 1 этот поток трафика обозначен синей пунктирной линией.
  3. HTTP-трафик из браузеров ПК сразу поступает в модуль предварительной обработки заголовков HTTP. Так как в заголовке HTTP нет удостоверения личности пользователя, для этого вида трафика WebSEAL запрашивает и проверяет подлинность пользователя. На рисунке 1 этот поток трафика обозначен зеленой сплошной линией.

В следующих разделах мы расскажем:

  • как работает SSO с использованием заголовков HTTP WebSEAL;
  • как шлюзы i-mode и WAP 2.0 выполняют идентификацию пользователя в HTTP-трафике;
  • как настроить WebSEAL на выполнение функции SSO для HTTP-трафика, который уже аутентифицирован шлюзами i-mode и WAP 2.0;
  • как построить решение, показанное на рисунке 1, используя WebSEAL;
  • как создать модуль предварительной обработки заголовков HTTP-трафика из шлюзов, который содержит номер мобильного телефона не в заголовке HTTP.

В последнем разделе мы рассмотрим альтернативные решения с использованием плагинов Web-сервера TAMeb.

1.2 Поток HTTP-трафика из мобильных устройств в мобильный портал

Рассмотрим, как попадает в мобильный портал HTTP-трафик от мобильных устройств 2/2.5/3G.

  1. Мобильное устройство посылает запрос на аутентификацию в шлюз WAP по протоколу RADIUS.
  2. Шлюз WAP выполняет аутентификацию пользователя через сервер RADIUS.
  3. Если пользователь аутентифицирован успешно, устанавливается соединение, и телефон получает возможность отправлять HTTP-запросы. Когда шлюз WAP/GPRS/3G получает HTTP-трафик, он вставляет номер мобильного телефона в cookie-файлы или заголовки HTTP и передает HTTP-трафик в центральный портал.

Шлюз i-mode аналогичен WAP-шлюзу, только номер мобильного телефона вставляется в строку запроса HTTP. Общая схема потока HTTP-трафика показана на рисунке 2.

Рисунок 2. Поток HTTP-трафика из мобильного устройства в центральный портал
Поток HTTP-трафика из мобильного устройства в центральный портал
Поток HTTP-трафика из мобильного устройства в центральный портал

1.3 Аутентификация пользователя в шлюзе WAP

Шлюз WAP используется для преобразования трафика WAP (Wireless Application Protocol) в трафик HTTP. Как правило, для целей проверки подлинности пользователей и учета он использует сервер RADIUS. Во многих моделях мобильных телефонов имеется SIM-карта (Subscriber Identity Module) - портативный чип памяти, содержащий персональную удостоверяющую информацию, номер мобильного телефона, телефонную книгу и другие данные. Телефонные номера, используемые для передачи и приема вызовов на мобильный телефон, называются MSISDN (Mobile Station International Subscriber Directory Number). Поскольку SIM-карта идентифицирует пользователя/абонента, успешное подключение телефона к шлюзу WAP/GPRS/3G означает, что он уже прошел систему аутентификации пользователей шлюза. Рисунок 3 иллюстрирует архитектуру аутентификации пользователей шлюза WAP.

Рисунок 3. Аутентификация пользователей шлюза WAP
Аутентификация пользователей шлюза WAP
Аутентификация пользователей шлюза WAP

1.4 Реализация SSO в WebSEAL на основе HTTP-заголовка

В некоторых случаях HTTP-трафик мог уже пройти проверку подлинности до прибытия на WebSEAL, – например, HTTP-трафик, поступающий из шлюза WAP/GPRS/3G или i-mode. В этом случае WebSEAL не следует вновь просить пользователя зарегистрироваться. Для этого требуется механизм SSO. На рисунке 4 показан сценарий SSO, в котором учетные данные встроены в HTTP-заголовок. Это происходит, когда клиент уже прошел проверку подлинности в других доверенных шлюзах. Вместо того чтобы заставлять пользователя повторно вводить учетные данные, эту информацию можно встроить в HTTP-заголовок для реализации SSO.

Рисунок 4. Последовательность аутентификации и авторизации с помощью HTTP-заголовка SSO
Последовательность аутентификации и авторизации с помощью HTTP-заголовка SSO
Последовательность аутентификации и авторизации с помощью HTTP-заголовка SSO
  1. Клиент направляет HTTP-запрос для доступа к мобильному порталу – ресурсу защищенного Web-пространства.
  2. Шлюз i-mode/WAP принимает HTTP-запрос. Шлюз проверяет подлинность клиента. В данном случае клиент подлинный.
  3. Шлюз i-mode/WAP вводит номер мобильного телефона клиента в HTTP-запрос. Затем HTTP-запрос направляется в WebSEAL.
  4. WebSEAL получает HTTP-запрос и проверяет, существует ли сеанс регистрации клиента. В данном случае сеанс регистрации не найден. Однако из HTTP-заголовка можно извлечь информацию SSO. WebSEAL передает эту информацию SSO в службу авторизации.
  5. Служба авторизации проверяет политику защиты объекта (protecting object policy – POP), чтобы убедиться, что IP клиента присутствует в списке доверенных IP. В данном случае он присутствует в списке доверенных IP, так как это IP-адрес шлюза.
  6. Служба авторизации рекомендует предоставить доступ.
  7. Создается сеанс регистрации.
  8. WebSEAL переадресует запрос на мобильный портал.

2 Идентификационная информация, распространяемая мобильными шлюзами

Как мы уже упоминали, удостоверением личности пользователя мобильного телефона служит номер мобильного телефона (MSISDN). Шлюз WAP/GPRS/3G или i-mode сохраняет номер мобильного телефона в заголовке HTTP, cookie-файле или строке запроса соответственно. Важно знать, как форматы этих удостоверений личности пользователя хранятся в HTTP-запросах, чтобы позже их можно было извлечь для проверки подлинности в рамках SSO. В этом разделе мы рассмотрим удостоверения личности пользователя шлюзов Ericsson WAP Gateway, Openwave WAP Gateway и i-mode Gateway.

2.1 Удостоверение личности пользователя WAP-шлюза Ericsson

Ericsson WAP Gateway вставляет MSISDN в заголовок HTTP_COOKIE. Содержание заголовков HTTP Ericsson WAP Gateway 1.0 и Ericsson WAP Gateway 3.0 немного различается. Как показано в таблице 1, значение MSISDN хранится в шестнадцатеричном формате. Например, если MSISDN имеет значение 88693974543, то поле User-Identity-Forward-msisdn имеет значение 3838363933393734353433. Мы покажем, как извлечь число MSISDN из шестнадцатеричного кода, в разделе "Разработка модуля предварительной обработки HTTP".

Таблица 1. Удостоверение личности пользователя шлюза Ericsson WAP Gateway
 Ericsson WAP Gateway 1.0 (в конце номера мобильного телефона запятая) 
 User-Identity-Forward-msisdn=383836393339373436353433,

 Ericsson WAP Gateway 3.0 (в конце номера мобильного телефона точка с запятой) 
 $Version=0;User-Identity-Forward-msisdn=383836393339373436353433;

2.2 Удостоверение личности пользователя шлюза WAP Ericsson

OpenWave WAP Gateway вставляет MSISDN в заголовок HTTP_x-up-calling-line-id. В отличие от Ericsson WAP Gateway, в HTTP_x-up-calling-line-id хранится само значение. Например, если MSISDN имеет значение 886939746543, то HTTP_x-up-calling-line-id=886939746543, как показано в таблице 2.

Таблица 2. Удостоверение личности пользователя шлюза WAP OpenWave
 HTTP_x-up-calling-line-id=886939746543

2.3 Удостоверение личности пользователя шлюза i-mode

Шлюз i-mode вставляет MSISDN в строку запроса. Как показано в таблице 3, строка запроса содержит несколько пар атрибутов имя-значение, разделенных знаком "&". Имя атрибута мобильного телефона – "PN".

Таблица 3. Удостоверение личности пользователя шлюза i-mode
 Строка запроса 

...&PN=886939746543&parameter1=value1&...

3 Разработка и настройка решения

3.1 Разработка модуля предварительной обработки HTTP для компонента WebSphere Edge

Как уже говорилось, компонент IBM WebSphere® Edge поддерживает плагины, что дает пользователям возможность писать свои собственные программы обработки HTTP-запросов. В этом разделе мы покажем, как разработать плагин dWork. Мы разрабатываем плагин предварительной обработки, который извлекает идентификатор пользователя MSISDN из каждого HTTP-запроса шлюза и вставляет его в HTTP-заголовок SSO WebSEAL. Исходный код можно загрузить по ссылке, приведенной в разделе загрузок настоящей статьи. Плагин предназначен для работы на платформе AIX®, поэтому для просмотра исходных кодов необходимо подготовить среду IBM XL C/C++ V8.0 для AIX. Подробнее об XL C/C++ см. на странице http://www-306.ibm.com/software/awdtools/xlcpp/. После установки XL C/C++ 8.0 нужно установить последние пакеты исправлений; иначе при компиляции плагина dWork будет выдаваться сообщение об ошибке (http://www-1.ibm.com/support/docview.wss?uid=swg1IY91535). Для компиляции необходимо скопировать исходный код в каталог /home/dWork и выполнить сценарий ./build.sh. Общая библиотека плагина dWork будет успешно создана в каталоге /home/dWork/lib. Подробнее о том, как разработать плагин Caching Proxy, читайте в разделе "Edge component" ресурса WebSphere Application Server InfoCenter http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp. Подробное описание списка файлов исходного кода плагина dWork приведено в таблице 4.

Таблица 4. Список файлов исходного кода плагина dWork
Исходный кодОписание
/home/dWork/build.shСоставьте сценарий. После копирования файл должен иметь атрибут executable. В противном случае нужно использовать "chmod +x build.sh" для изменения атрибута файла.

/home/dWork/cp/HTAPI.h

/home/dWork/cp/htctypes.h

/home/dWork/cp/libhttpdapi.exp

Эти три файла появятся после установки Caching Proxy. Скопируйте их из каталога Caching Proxy.
/home/dWork/etc/dWork.confФайл конфигурации, используемый плагином dWork. В этом файле должны быть указаны IP-адреса шлюзов WAP и i-mode.
/home/dWork/lib/dWorkPlugin.soОбщая библиотека плагина dWork.

/home/dWork/src/config.cxx

/home/dWork/src/dWorkPlugin.cxx

/home/dWork/src/init.cxx

/home/dWork/src/config.h

/home/dWork/src/dWorkPlugin.h

/home/dWork/src/inti.h

Исходные коды для чтения файла конфигурации dWork.conf.

Точка входа и основная логика плагина dWork.

Точка входа для инициализации плагина dWork.

Заголовок файла config.cxx.

Заголовок файла dWorkPlugin.cxx.

Заголовок файла init.cxx.

Рассмотрим логику исходного кода подробнее. В примере 1 приведен фрагмент плагина dWork. Посмотрим, как он работает при использовании Ericsson WAP Gateway.

  1. На шаге 1 плагин получает значения HTTP_COOKIE, так как Ericsson WAP Gateway помещает туда номер мобильного телефона.
  2. На шаге 2 плагин извлекает MSISDN из HTTP-заголовка HTTP_COOKIE, добавленного шлюзом Ericsson WAP. В примере 2 легко увидеть, что HTTP заголовок SSO TAMeb создается путем извлечения строки MSISDN из HTTP_COOKIE и дополнения ее именем TAMeb.
  3. На шаге 3 плагин вставляет MSISDN, подготовленный на предыдущем шаге, в HTTP-заголовок для SSO WebSEAL. Если HTTP-трафик из шлюзов отсутствует, HTTP-заголовок для SSO WebSEAL нужно удалить.

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

Пример 1. Точка входа плагина Caching Proxy
//Точка входа плагина Caching Proxy 
extern "C" void HTTPD_LINKAGE mobileSSO
(unsigned char *handle, long *return_code) {

 occurrence = 0;
<Шаг 1>httpcookievalue = httpd_getvar(handle, 
 (unsigned char *)HTTP_COOKIE, &occurrence);
remoteAddress = httpd_getvar(handle,
 (unsigned char *)REMOTE_ADDR, &occurrence);
...
...
...

 //Ericsson WAP 2.0 Gateway
 } else if ( !strcmp((const char*)remoteAddress, 
 ProfileData::ERICSSON_GATEWAY_IP)) {
	.....
<Шаг 2>result=getEricssonMSISDN(httpcookievalue,MSISDN);
...
...
...
} else {
	printf("The HTTP traffic comes from non-Gateway 
	IP %s.\n",(const char*)remoteAddress);
	result = 500;
}
if (result==0) {
	//вставка MSISDN для HTTP-заголовка 
	WebSEAL Sign Token в HTTP-заголовок
<Шаг 3>returnValue = httpd_setvar(handle,  (unsigned char*)TAM_SSO_TOKEN, (unsigned char *)(const char *)MSISDN, (unsigned long*)HTTPD_SETVAR_REPLACE_ADD);
...
...
...
} else {
 //Необходимо удалить TAM_SSO_TOKEN, если 
HTTP-трафик происходит //не из шлюза i-mode или WAP.
Это делается для //предотвращения возможности отправки хакерами //запросов HTTP и введения в TAM_SSO_TOKEN. printf("Can't get the MSISDN for SSO. The reason code is %d.\n", result); printf("Remove %s for security reason.\n", (unsigned char*)TAM_SSO_TOKEN); returnValue = httpd_setvar(handle, (unsigned char*)TAM_SSO_TOKEN, (unsigned char *)blank, (unsigned long*)HTTPD_SETVAR_REMOVE_ALL);
	}
}

В следующем разделе мы на примере шлюза Ericsson WAP Gateway покажем, как получить MSISDN. Работу плагина со шлюзами OpenWave и i-mode можно посмотреть в исходных кодах к этой статье.

3.1.1 Ericsson WAP Gateway

Как уже говорилось, Ericsson WAP Gateway вставляет MSISDN в заголовок HTTP_COOKIE. Так как значение HTTP_COOKIE имеет шестнадцатеричный формат, мы в примере 2 продемонстрируем, как извлечь значение MSISDN для Ericsson. Основной код, используемый для извлечения номера мобильного телефона, помечен полужирным шрифтом.

Пример 2. Извлечение MSISDN из HTTP_COOKIE
int getEricssonMSISDN(const unsigned char *longStr, char *MSISDN) {
...
...
...
 msisdnStr=strstr((char *)longStr, (const char *)"User-Identity-Forward-msisdn");
 if (msisdnStr==NULL) {
 printf("Can't find MSISDN in the %s.\n", HTTP_COOKIE);
 return 102; 
 }
 //Если в HTTP_COOKIE присутствует строка 
 "User-Identity-Forward-msisdn",
 //продолжаем разбор cookie с разделителем ";" или ",".
 //EricssonWG 1.0 использует в качестве разделителя "," а 3.0 – ";". 
 msisdnStr=strtok(msisdnStr,(const char *)",;");
 if (msisdnStr==NULL){
 printf("MSISDN в %s не найден .\n", HTTP_COOKIE);
 return 103;
 }
 //продолжаем разбор cookie с разделителем "=".
 msisdnStr=strtok(msisdnStr,(const char *)"=");
 if (msisdnStr==NULL){
 printf("Строка в формате MSISDN 
 в %s не найдена .\n",HTTP_COOKIE);
 return 104;
 } 
 //Извлечение строки до разделителя "=". 
 msisdnStr=strtok(NULL,(const char *)"=");
 if (msisdnStr==NULL) {
	 printf("Строка в формате 
	 MSISDN в %s не найдена .\n", HTTP_COOKIE);
 return 105;
 }
...
...
...
 //Извлечение MSISDN из шестнадцатеричного кода.  
 //Достаточно просто извлечь цифры из четных позиций.
 for (i=1; i<length; i=i+2){ MSISDN[j++]=msisdnStr[i]; } MSISDN[j]=0x0; //Пустой конец строки
 strcat(MSISDN,ProfileData::TAM_REALM_NAME);
 return 0; //Возвращает 0, если обработка прошла успешно..
}

3.2 Настройка плагина dWork для Caching Proxy

Теперь мы покажем, как настроить плагин dWork для Caching Proxy.

  1. Скопируйте /home/dWork/lib/dWorkPlugin.so в /usr/lib. Файл должен иметь доступ для чтения. (Используйте команду chmod +r /usr/lib/dWorkPlugin.so.)
  2. Скопируйте /home/dWork/etc/dWork.conf в /etc/dWork.conf. Файл должен иметь доступ для чтения. (Используйте команду chmod +r /etc/dWork.conf.)
  3. Проверьте конфигурации /etc/dWork.conf. Убедитесь, что IP-адреса шлюзов указаны правильно.
  4. Измените файл конфигурации Caching Proxy /etc/ibmproxy.conf следующим образом. (Перед изменением файла мы рекомендуем создать его резервную копию. )
  5. Перезапустите Caching Proxy (чтобы остановить Caching Proxy, используйте команду "stopsrc -s ibmproxy"; чтобы запустить Caching Proxy, используйте команду "startsrc -s ibmproxy".)
Пример 3. Конфигурация для установки плагина dWork в Caching Proxy
### Ниже приведены конфигурационные настройки плагина dWork ###
### Эти настройки должны содержаться в файле ibmproxy.conf. ###
# ====================================================== #
#Директивы API:
# ====================================================== #
### Конфигурационные настройки плагина dWork ###
ServerInit /usr/lib/dWorkPlugin.so:InitdWork /etc/dWork.conf
PreExit /usr/lib/dWorkPlugin.so:mobileSSO
...
...
...

# ======================================================= #
#
# Правила отображения
#
# ======================================================== #
...
...
...
### Определение правила отображения для
 маршрутизации запроса к серверу WebSEAL.  ###### Например,
предположим, что имя хоста Caching Proxy – server0.ibm.com. ###### Имя хоста WebSEAL server1.tw.ibm.com ###### HTTP-запрос http://server0.ibm.com/webseal/webservice1 ###### будет направлен по адресу: http://server1.ibm.com/webservice1. ###Proxy /webseal/*	http://server1.ibm.com/*

3.3 Настройка WebSEAL

3.3.1 Настройка аутентификации заголовка

В этом разделе мы покажем, как настроить аутентификацию HTTP-заголовка WebSEAL. Это делается посредством файла конфигурации WebSEAL webseald-instance_name.conf. Он находится в одном из следующих каталогов.

В Linux и UNIX: /opt/pdweb/etc. 
В  Windows: <основной каталог WebSEAL >\etc

Чтобы определить способ аутентификации HTTP-заголовка, нужно найти и изменить следующие параметры. В примере 4 в качестве доверенного HTTP-заголовка мы используем X-IBM-PVC-User.

Пример 4. Пример настройки процесса аутентификации HTTP-заголовка
ba-auth = none
...
mpa = no
...
require-mpa = no
...
ssl-id-sessions = no 
...
[session-http-headers]
X-IBM-PVC-User = http
X-IBM-PVC-User = https
...
[http-headers]
http-headers-auth = both
...
[auth-headers]
header = X-IBM-PVC-User
...
[authentication-mechanisms]
http-request = <Ваш модифицированный модуль XAUTHN 
(см. примечание ниже).
#### Например:: /usr/lib/libauthn.so #######
Важное замечание
Типы HTTP-заголовков, поддерживаемых WebSEAL, указаны в разделе [auth-headers] файла конфигурации WebSEAL. По умолчанию встроенный модуль (libhttpauthn.so for AIX) поддерживает только данные заголовка Entrust Proxy. Этот встроенный по умолчанию модуль нельзя использовать для реализации SSO со шлюзом WAP/i-mode Gateway. Чтобы решить эту проблему, мы предлагаем специальный модуль External Authentication (далее – XAUTHN) в качестве образца для проверки подлинности заголовка HTTP. Исходный код этого модуля и двоичную библиотеку для AIX можно загрузить по ссылке в разделе "Загрузки". Подробнее о том, как реализовать этот модуль, см. в руководстве IBM Tivoli Access Manager for e-business Web Security Developer Reference.

3.3.2 Ограничение доступа к WebSEAL

Так как мы разрешаем доступ к WebSEAL только мобильным шлюзам, необходимо определить перечень доверенных IP-адресов. Список доверенных IP-адресов ограничивает доступ, так что только доверенные клиенты могут выполнять аутентификацию и авторизацию на сервере WebSEAL. Это можно сделать, добавив политику защиты объектов (POP) к объектам в пространстве объектов TAMeb. Чтобы определить список доверенных IP-адресов, нужно войти в утилиту pdadmin с правами администратора. Затем следует выполнить действия, описанные в примере 5. В этом примере мы добавляем политику защиты объектов в корневой каталог пространства объектов WebSEAL. IP-адреса шлюзов i-mode, WAP 2.0/GRPS/3G должны значиться в списке доверенных IP-адресов.

Важное замечание
В дополнение к использованию политики защиты объектов WebSEAL мы рекомендуем использовать защиту сетевого уровня посредством межсетевого экрана/виртуальной локальной сети (VLAN) для более надежного ограничения доступа к WebSEAL.
Пример 5. Пример настройки списка доверенных IP-адресов
pdadmin sec_master> pop create poptest1
pdadmin sec_master> pop modify poptest1 set ipauth anyothernw forbidden
pdadmin sec_master> pop modify poptest1 set ipauth add < IP доверенного клиента>
255.255.255.255 0
pdadmin sec_master> pop attach /WebSEAL poptest1

Чтобы политика защиты объектов работала правильно, нужно убедиться, что в списке управления доступом учетной записи пользователя не установлен бит действия "R" (bypass pop rule). Ниже приведены команды для поиска битов действия в учетной записи пользователя.

  1. Команда object show <object name> ищет ACL для объекта.
  2. Команда acl show <acl name> ищет биты действия пользователей или групп в ACL.

3.3.3 Тестирование SSO WebSEAL

Простой способ тестирования SSO заключается в использовании Linux®-команды curl. Команда curl позволяет отправлять HTTP-запросы со специальными HTTP-заголовками и cookie-файлами. Если параметр junction установлен неправильно, вы попадете на страницу регистрации. Так как мы используем команду curl для имитации HTTP-трафика из шлюзов i-mode/WAP2.0/GPRS/3G, нужно внести IP-адрес машины, используемой для выполнения команды curl, в список доверенных IP-адресов.

Проверка SSO при помощи команды curl:
# curl -H "X-IBM-PVC-User: sec_master" http://server1.ibm.com/webservice1

Здесь sec_master – идентификатор администратора Tivoli Access Manager по умолчанию. URL http://server1.ibm.com/webservice1 отображается на страницу http://server2.ibm.com.

3.4 Тестирование полного решения

В этом разделе приведен полный тест потока HTTP-трафика SSO между шлюзом Ericsson/OpenWave/i-mode и WebSEAL. При отсутствии реальных шлюзов WAP или i-mode HTTP-трафик можно имитировать с помощью команды curl. Перед началом теста необходимо создать пользователей в TAMeb, применив номер мобильного телефона в качестве идентификатора пользователя. Например, в TAMeb можно создать идентификатор пользователя 886939746543. HTTP-трафик, исходящий из тестовой машины curl (предположим, что IP-адрес машины curl 172.16.136.126), проходит через прокси-сервер кэширования. Поэтому его IP-адрес должен быть правильно настроен в качестве доверенного IP-адреса POP WebSEAL, как описано в разделе "Ограничение доступа к WebSEAL". IP-шлюз (172.16.136.126) следует указать и в файле /etc/dWork.conf. В качестве примера для демонстрации пошаговой процедуры тестирования будем использовать Ericsson WAP Gateway.

  1. Отредактируйте файл /etc/dWork.conf и убедитесь, что в качестве IP-адреса Ericsson WAP Gateway указан 172.16.136.126.
    Пример 6. Пример файла /etc/dWork.conf для Ericsson WAP Gateway
    IMODE_GATEWAY_IP 10.10.1.1
    ERICSSON_GATEWAY_IP 172.16.136.126
    OPENWAVE_GATEWAY_IP 10.10.1.3
    TAM_REALM_NAME @IBM
  2. Перезапустите Caching Proxy, чтобы изменения, внесенные в файл /etc/dWork.conf, вступили в силу.
  3. Убедитесь, что IP-адрес прокси-сервера кэширования правильно настроен в качестве доверенного IP-адреса POP WebSEAL.
  4. Воспользуйтесь командой curl для имитации HTTP-трафика из шлюза WAP Ericsson/OpenWave/i-mode.
    // Предполагаем, что Caching Proxy  – это server0.ibm.com.
    
    // Для HTTP-трафика из Ericsson WAP Gateway
    # curl -b "User-Identity-Forward-msisdn=383836393339373436353433"
    http://server0.ibm.com/webseal/webservice1
    
    // Для HTTP-трафика из OpenWave WAP 2.0 Gateway
    # curl -H "x-up-calling-line-id:886939746543" 
    http://server0.ibm.com/webseal/webservice1
    
    // Для HTTP-трафика из i-mode Gateway
    # curl http://server0.ibm.com/webseal/webservice1?PN=886939746543
  5. Ответом не должна быть форма регистрации.

4 Альтернативное решение с использованием плагина TAMeb для Web-серверов

Как и WebSEAL, плагин для Web-серверов представляет собой альтернативный менеджер ресурсов, который также поддерживает проверку подлинности и авторизации по HTTP-заголовкам. Его файл конфигурации можно настроить аналогично файлу конфигурации webseald-instance_name.conf. В следующих разделах мы приведем архитектуру и конфигурации с использованием плагина TAMeb для Web-серверов.

4.1 Архитектура компонента

На рисунке 5 приведена общая архитектура с использованием в качестве менеджера ресурсов аутентификации и авторизации плагина TAMeb для Web-серверов, вместо WebSEAL.

Рисунок 5. Использование плагина TAMeb для Web-серверов в качестве менеджера ресурсов
Использование плагина TAMeb для Web-серверов в качестве менеджера ресурсов
Использование плагина TAMeb для Web-серверов в качестве менеджера ресурсов

4.2 Настройка аутентификации по HTTP-заголовку

  1. Остановите плагин TAMeb для Web-серверов
  2. Найдите файл конфигурации плагина TAMeb для Web-серверов. Это файл с именем pdwebpi.conf.
  3. Найдите раздел common-modules и установите значение параметра проверки подлинности равным http-hdr, как показано ниже.
    [common-modules]
    authentication = http-hdr
  4. Найдите раздел modules и установите значение параметра http-hdr равным pdwpi-httphdr-module, как показано ниже.
    [modules]
    http-hdr = pdwpi-httphdr-module
  5. Ниже раздела modules добавьте раздел http-hdr. Установите значение параметра заголовка равным выбранному имени заголовка, как показано ниже.
    [http-hdr]
    header = <имя заголовка>
    ## В этой статье используется X-IBM-PVC-User ##
  6. Найдите раздел authentication-mechanisms и установите значение параметра http-request равным местоположению специального модуля XAUTHN.
    Например:
    [authentication-mechanisms]
    http-request = <местоположение измененного вами модуля XAUTHN>
    ## В этой статье используется /usr/lib/libauthn.so ##
  7. Запустите плагин TAMeb для Web-серверов.

5 Заключение

В этой статье мы показали решение SSO на базе TAMeb и шлюзов WAP/GPRS/3G или i-mode. Его можно использовать для создания порталов для мобильных телефонов разного типа. В качестве примера мы разработали плагин Caching Proxy для SSO на базе плагина WebSEAL или TAMeb для шлюзов Ericsson Openwave WAP 2.0 Gateway и i-mode Gateway. Такое решение может служить хорошим образцом для разработки архитектуры порталов для мобильных телефонов. Приведенный пример легко адаптировать для других шлюзов (таких как шлюз WAP Nokia). Прочитав эту статью, вы сможете легко изменить исходный код так, чтобы он соответствовал требованиям вашего мобильного портала.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=632794
ArticleTitle=Единый вход на базе WebSEAL для телекоммуникационных шлюзов WAP 2.0/GPRS/3G
publish-date=03182011