Об этом уроке
Это руководство, второе из серии из трех частей, объясняет, как разработать систему управления идентификацией на основе единого входа с использованием Shibboleth IDP и SP. Это также покажет, как вы можете просматривать ресурсы нескольких приложений с помощью единого механизма входа в систему.
Цели
Из этого урока вы узнаете, как:
- Установите и настройте Shibboleth Identity Provider и Service Provider с веб-сервером Apache в Ubuntu.
- Интегрируйте свои пользовательские приложения с функцией единого входа через Shibboleth.
- Захватите атрибуты пользователя из Shibboleth IDP в вашем приложении.
Предпосылки
В этом руководстве предполагается, что вы знакомы с некоторыми основными понятиями управления идентификацией и единого входа. Выполните следующие шаги для установки и настройки сервера приложений, веб-сервера Apache и Open-LDAP, необходимых для этого руководства.
Загрузки
- Apache Tomcat 7.
- Джава
Загрузите самораспаковывающийся установщик (для 32-разрядной или 64-разрядной системы)
- Открыть Ldap
Настроить
I) JAVA: JDK установлен, а JAVA_HOME установлен в bashrc или в профиле.
Если JDK не установлен и не настроен, загрузите его из Oracle и выполните следующие шаги для настройки.
Перейдите в каталог, в который вы его скачали: cd / home / kuntal / Downloads
Теперь выполните его ./jdk-6u27-linux-i586.bin, вы увидите новый каталог jdk1.6.0_27 — - будет называть это JAVA_HOME.
Настройте дом JAVA в bashrc или экспортируйте профиль JAVA_HOME = / home / kuntal / Downloads / jdk1.6.0_27
II) Локальный домен: создайте имя локального домена для вашего IP в сети.
sudo vi / etc / hosts и добавьте в него следующую запись:
127.0.1.1 kuntal.example.org
III) Установка OpenSSL. Чтобы установить универсальную библиотеку OpenSSL, сначала определите подходящую версию библиотеки, доступную для вашего компьютера с Ubuntu, с помощью следующей команды, введенной в командной строке терминала:
apt-cache search libssl | grep SSL
Вы должны наблюдать вывод команды, подобный следующему:
libssl0.9.6 - SSL shared libraries (old version) libssl-dev - SSL development libraries, header files and documentation libssl0.9.7 - SSL shared libraries
В приведенном выше примере вы, скорее всего, захотите установить текущую библиотеку OpenSSL, которая отображается в выходных данных как libssl0.9.7 (например, sudo apt-get install libssl0.9.7)
IV) Установка Apache 2: веб-сервер Apache2 доступен в Ubuntu Linux.
установить Apache2: в командной строке терминала введите следующую команду.
sudo apt-get install apache2
SSL-сертификаты Apache2:
Enable SSL sudo a2enmod ssl
Перезапустите apache2:
sudo /etc/init.d/apache2 restart
Создайте новый каталог, в котором мы будем хранить ключ сервера и сертификат:
sudo mkdir /etc/apache2/ssl
Создание самозаверяющих SSL-сертификатов. Когда мы запрашиваем новый сертификат, мы можем указать, как долго сертификат должен оставаться действительным, изменив 365 на количество дней, которое мы предпочитаем. Срок действия этого сертификата истекает через год.
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Настройте виртуальные хосты для отображения нового сертификата:
sudo vi /etc/apache2/sites-available/default-ssl
В разделе, который начинается с <VirtualHost _default_: 443>, быстро внесите следующие изменения.
Найдите следующие строки и убедитесь, что они соответствуют расширениям ниже:
SSLEngine on SSLCertificateKeyFile /etc/apache2/ssl/apache.key SSLCertificateFile /etc/apache2/ssl/apache.crt
Добавьте строку с вашим именем сервера в
httpd.conf: sudo vi /etc/apache2/httpd.conf
Имя сервера: kuntal.example.org
Прежде чем веб-сайт, который будет подключен к порту 443, может быть активирован, нам нужно включить этот виртуальный хост:
sudo a2ensite default-ssl
Перезапустите apache2:
sudo /etc/init.d/apache2 restart
V) Tomcat настроен
Создайте каталог sso:
mkdir /home/kuntal/Kuntal/sso
Переместиться в этот каталог:
cd /home/kuntal/Kuntal/sso
Распакуйте скачанный дистрибутив Tomcat:
tar -xvzf apache-tomcat-6.0.39.tar.gz
Это будет ссылаться на этот извлеченный кот как на IDP-сервер.
Создайте еще один каталог для сервера приложений:
mkdir /home/kuntal/Kuntal/sso/appServer
Это будет ссылаться на кота внутри него как на appServer.
Скопируйте извлечение tomcat в каталог appServer:
cp /apache-tomcat-6.0.39 /home/kuntal/Kuntal/sso/appServer
Настройка Tomcat AppServer и SSL: Перейдите в каталог bin JAVA_HOME
cd /home/kuntal/Downloads/jdk1.6.0_27bin
Выполните следующие команды, чтобы сгенерировать файл хранилища ключей и доверенных сертификатов вместе с их паролем:
./keytool -genkey -alias localhost -keyalg RSA -keystore /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssocert
Примечание: пожалуйста, напишите имя вашего локального домена, когда вас попросят указать ваше имя и фамилию.
./keytool -export -alias localhost -storepass changeit -file /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssoclient.cer -keystore /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssocert
./keytool -import -trustcacerts -alias localhost -storepass changeit -file /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssoclient.cer -keystore "/home/kuntal/Downloads/jdk1.6.0_27/jre/lib/security/cacerts"
Теперь отредактируйте appServer server.xml, чтобы включить ssl с указанными выше сертификатами:
sudo vi /home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/server.xml
Обновите или добавьте (если не включено) следующее:
<Connector port="8543" protocol="org.apache.coyote.http11.Http11Protocol" SSLImplementation="edu.internet2.middleware.security.tomcat6.DelegateToApplicationJSSEImplementation" scheme="https" SSLEnabled="true" clientAuth="want" keystoreFile="/home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/conf/ssocert" keystorePass="changeit" truststoreFile ="/home/kuntal/Downloads/jdk1.6.0_27/jre/lib/security/cacerts" truststorePass ="changeit"/>
Также обновите коннектор http по умолчанию и конфигурацию порта коннектора AJP1.3:
<Connector port="8090" protocol="HTTP/1.1"
connection Timeout="20000"
redirectPort="8543" />
<Connector port="8010" protocol="AJP/1.3" redirect Port="8543" />
Сервер IDP будет работать на 8080 для http и 8443 для https. Поэтому appServer будет работать на 8090 для http и 8543 для https, так как мы работаем на обоих серверах на одном компьютере. Теперь запустите appServer и проверьте, правильно ли он работает на вышеупомянутом порту:
Начните с выполнения:
/home/kuntal/Kuntal/sso/appServer/apache-tomcat-6.0.39/bin/startup.sh
(Впервые ваш браузер может попросить SSL-сертификат не доверять, но в любом случае нажмите кнопку «Продолжить», чтобы проверить домашнюю страницу tomcat)
Балансировка нагрузки сервера приложений Tomcat с веб-сервером Apache2. Настройте mod_jk с помощью Apache2 в Ubuntu. Установить mod_jk: чтобы установить mod_jk в Ubuntu, выполните следующую команду в командной строке.
sudo apt-get install libapache2-mod-jk
Откройте файл jk.conf, чтобы найти местоположение worker.properties:
sudo vi /etc/apache2/mods-available/jk.confl JkWorkersFile /etc/libapache2-mod-jk/workers.properties
Обновите файл свойств работника для нашего appServer:
# Define 1 real worker named ajp13 worker.list=ajp13 # Set properties for worker named ajp13 to use ajp13 protocol, # and run on port 8009 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.lbfactor=50 worker.ajp13.cachesize=10 worker.ajp13.max_packet_size=65536 worker.ajp13.cache_timeout=600 worker.ajp13.socket_keepalive=1 worker.ajp13.socket_timeout=300 # Enable load balancer for this worker worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=ajp13
Сконфигурируйте переадресацию URL в apache на tomcat. Добавьте следующие строки в ваш виртуальный хост apache для пересылки запросов на tomcat:
sudo vi /etc/apache2/sites-available/default
<VirtualHost *:80>
...
# Send everything for appA and aapB to worker ajp13
JkMount /appA ajp13
JkMount /appA/* ajp13
JkMount /appB ajp13
JkMount /appB/* ajp13
...
</VirtualHost>
sudo vi /etc/apache2/sites-available/default-ssl
<VirtualHost _default_:443>
...
# Send everything for appA and aapB to worker ajp13
JkMount /appA ajp13
JkMount /appA/* ajp13
JkMount /appB ajp13
JkMount /appB/* ajp13
...
</VirtualHost>
Перезапустите сервер Tomcat (appServer) и Apache.
VI) OpenLdap настроен
Судо Установка
sudo apt-get update sudo apt-get install slapd ldap-utils
Вам будет предложено ввести и подтвердить пароль администратора для учетной записи администратора LDAP.
Когда установка завершится, нам действительно нужно перенастроить пакет LDAP. Введите следующую команду, чтобы вызвать инструмент конфигурации пакета:
sudo dpkg-reconfigure slapd
Вам будет задан ряд вопросов о том, как вы хотите настроить программное обеспечение.
Нет никаких установленных правил для того, как настроить это. Если у вас есть фактическое доменное имя на этом сервере, вы можете использовать его. В противном случае, используйте то, что вы хотите.
В этом уроке мы будем называть его kuntal.example.org (как мы уже установили имя doamin).
Мы будем администрировать LDAP через веб-интерфейс PHPldapadmin.
Установите его с помощью этой команды:
sudo apt-get install phpldapadmin
Теперь навигация в вашем браузере:
Авторизоваться:
LoginDN--> cn=admin,dc=kuntal,dc=example,dc=org
Пароль → {Вы создали во время установки openldap} (ldapadmin) для этого урока.
Теперь создайте несколько групп и пользователей вместе с их паролем.
Вступление
Что такое Шибболет?
Проще говоря, Shibboleth — это федеративная система управления идентификацией для единого входа в Интернет. Давайте разберемся с этим:
Единая регистрация — вы входите в один ресурс, и при посещении следующего ресурса вы автоматически входите в систему. Почему это важно? Не нужно повторно аутентифицировать пользователей при их перемещении с ресурса на ресурс.
Управление идентификацией . Цель Shibboleth — управление идентификацией пользователей и их ключевыми атрибутами идентификации, такими как имя, адрес электронной почты, роль, независимо от того, прошли ли вы аутентификацию и кто вас аутентифицировал.
Федеративный — это означает, что он работает «через домены». Например, freemail.com может принимать пользователей как от себя, так и от gmail.com. Почему это важно? Вам не нужно размещать службу в своем домене, чтобы воспользоваться единой регистрацией.
Почему Шибболет?
Есть много веских причин для этого:
- Ваши пользователи не получат carpel-tunnel от ввода их пароля 20x в день. Если вы являетесь организацией, вашим пользователям понравятся преимущества единого входа. Как только они проходят аутентификацию у вашего провайдера идентификации, они автоматически входят в систему различных провайдеров услуг.
- Пароли ваших пользователей не передаются как партию на вечеринке 70-х. Поставщики услуг не аутентифицируют пользователей. Они просят поставщика удостоверений сделать это для них. В результате ваш пароль никогда не видится и не сохраняется поставщиками услуг. Если вы пишете приложение, которое будет поставщиком услуг, вам не нужно беспокоиться о хранении паролей.
- Безопаснее, чем «войти через Facebook» или «войти через Twitter». Вы контролируете личность вашего пользователя, а не какой-то легкий запуск. ИТ-отделы радуются.
- Простота «Shibbolize» Добавление поддержки Shibboleth в любое приложение относительно просто, просто выясните, что делать с «принятыми» атрибутами, которые вы получаете от установленного поставщика услуг, и работайте с ним.
Настройка и настройка
Shibboleth Set Up
1. Сделать каталог для скачивания
Переместить в каталог sso
cd /home/kuntal/Kuntal/sso
Сделать каталог шибболет
mkdir /home/kuntal/Kuntal/sso/shibboleth
и двигаться в это
cd /home/kuntal/Kuntal/sso/shibboleth
Теперь выполните следующие команды одну за другой:
Примечание: вы можете получить ошибку предварительной проверки. Поэтому убедитесь, что у вас есть g ++, установите версию заголовка Boost. В противном случае установите его с помощью →
sudo apt-get install g++
sudo apt-get install libboost-all-dev
sudo apt-get install libssl-dev
sudo apt-get install libcurl4-openssl-dev
sudo apt-get install apache2-prefork-dev
2. Скачать шибболет
Dowanload SP:
wget http://shibboleth.net/downloads/service-provider/latest/shibboleth-sp-2.5.3.tar.gz
Скачать IDP:
wget http://shibboleth.net/downloads/identity-provider/latest/shibboleth-identityprovider-2.4.0-bin.tar.gz
Загрузите OpenSaml:
wget http://shibboleth.net/downloads/c++-opensaml/latest/opensaml-2.5.3.tar.gz
Скачать log4shib
wget http://shibboleth.net/downloads/log4shib/latest/log4shib-1.0.8.tar.gz
Скачать набор инструментов xml:
wget http://shibboleth.net/downloads/c++-opensaml/latest/xmltooling-1.5.3.tar.gz
Скачать xml security
wget http://www.apache.org/dyn/closer.cgi?path=/santuario/c-library/xml-security-c-1.7.2.tar.gz
Скачать Xerces
wget http://apache.arvixe.com//xerces/c/3/sources/xerces-c-3.1.1.tar.gz
3. Извлеките весь файл tar.gz с помощью ->
tar -xzvf command
4. Установка Shibboleth IDP
Перейти к извлеченному каталогу Shibboleth IDP.
cd /home/kuntal/Kuntal/sso/shibboleth/shibboleth-identityprovider-2.4.0
Выполнить (Убедитесь, что на вашем компьютере настроен apache ant с правильно установленным ANT_HOME)
./install.sh
Он попросит вас указать каталог, в который вы хотите установить IDP Shibboleth.
Где должно быть установлено программное обеспечение Shibboleth Identity Provider?
Введите следующее:
/home/kuntal/Kuntal/sso/shibboleth-idp
5. После установки IDP:
Скопируйте файл idp.war из ~ / sso / shibboleth-idp / war и вставьте его в каталог веб-приложения сервера IDP tomcat.
cp /home/kuntal/Kuntal/sso/shibboleth-idp/war/idp.war /home/kuntal/Kuntal/sso/apache-tomcat-6.0.39/webapps
Обновите server.xml сервера tomcat IDP.
Листинг 1. Tomcat IDPServer’s server.xml
<Connector port="8443"
protocol="org.apache.coyote.http11.Http11Protocol"
SSLImplementation="
edu.internet2.middleware.security.tomcat6.DelegateToApplicationJSSEImplementation"
scheme="https"
SSLEnabled="true"
clientAuth="want"
keystoreFile="/home/kuntal/Kuntal/sso/shibboleth-idp/credentials/idp.jks"
keystorePass="changeit" />
Создайте имя каталога, одобренное на домашнем сервере IDP. Затем скопируйте и вставьте библиотеки, связанные с XML, из одобренного каталога домашней установки Shibboleth IDP.
/home/kuntal/Kuntal/sso/shibboleth-idp/lib to IDP server home /home/kuntal/Kuntal/sso/apache-tomcat-6.0.39/endorsed.
Также скопируйте файл tomcat-dta-ssl.jar из исходного кода в каталог IDP Server_HOME / lib.
6. Теперь перезапустите сервер tomcat IDP.
Вы увидите информацию о IDP и системе.
7.
Установка Shibboleth SP:
Установка Shibboleth SP:
Перейдите в каталог sso / shibboleth
cd / home / кунталь / кунталь / ссо / шибболет /
Теперь выполните следующие команды одну за другой:
Перейдите в каталог log4shib и выполните:
./configure —disable-static —disable-doxygen —prefix = / home / kuntal / Kuntal / sso / shibboleth-sp && make && sudo make install
Перейдите в каталог xerces и выполните:
./configure —prefix = / home / kuntal / Kuntal / sso / shibboleth-sp && make && sudo make install
Перейдите в каталог xmlsecurity и выполните:
./configure —without-xalan —disable-static —with-xerces = / home / kuntal / Kuntal / sso / shibboleth-sp —prefix = / home / kuntal / Kuntal / sso / shibboleth-sp && make && sudo make install
Перейдите в каталог xmltooling и выполните:
./configure —with-log4shib = / home / kuntal / Kuntal / sso / shibboleth-sp —prefix = / home / kuntal / Kuntal / sso / shibboleth-sp -C && make && sudo make install
Переместитесь в каталог opensaml и выполните:
./configure —prefix = / home / kuntal / Kuntal / sso / shibboleth-sp —with-log4shib = / home / kuntal / Kuntal / sso / shibboleth-sp -C && make && sudo make install
Перейдите в каталог shibboleth-sp и выполните:
./configure —with-saml = / home / kuntal / Kuntal / sso / shibboleth-sp —enable-apache-22 —with-log4shib = / home / kuntal / Kuntal / sso / shibboleth-sp —with- xmltooling = / home / kuntal / Kuntal / sso / shibboleth-sp —prefix = / home / kuntal / Kuntal / sso / shibboleth-sp -C && make && sudo make install
Нет тэ:
В Ubuntu вы можете также установить Шибболет поставщик услуг с использованием:
В Ubuntu вы можете также установить Шибболет поставщик услуг с использованием:
sudo apt-get установить libapache2-mod-shib2 shibboleth-sp2-schemas
Но эта установка иногда не работает должным образом в различных версиях Ubuntu.
8. После установки SP:
Скопируйте содержимое сценария запуска shibd в /etc/init.d/shibd:
sudo touch /etc/init.d/shibd
Теперь обновите shibd следующим:
sudo vi /etc/init.d/shibd
Выполните эти команды, чтобы активировать Shibd:
sudo chmod + x /etc/init.d/shibd
Интеграция Shibboleth SP с Apache
Настройте Apache2 для использования модуля Shibboleth:
echo «export LD_LIBRARY_PATH = / home / kuntal / Kuntal / sso / shibboleth-sp / lib» | sudo tee -a / etc / apache2 / envvars
echo «LoadModule mod_shib /home/kuntal/Kuntal/sso/shibboleth-sp/lib/shibboleth/mod_shib_22.so» | sudo tee -a /etc/apache2/mods-available/shib2.load
echo «UseCanonicalName On» | sudo tee -a /etc/apache2/httpd.conf
Создать
shib2.conf
sudo vi /etc/apache2/mods-available/shib2.conf
Включите модуль shib2 в Apache и перезапустите Apache:
sudo a2enmod shib2
sudo /etc/init.d/apache2 restart
Откройте веб-браузер и укажите свой сайт по следующему пути Shibboleth:
Убедитесь, что вы видите это сообщение:
Действительный сеанс не был найден.
Потоки и Конфигурация
У Shibboleth есть две основные половины: провайдер идентификации (IdP) и провайдер услуг (SP). Поставщик удостоверений предоставляет информацию о пользователях службам, а поставщик услуг собирает информацию о пользователях для защиты ресурсов. В типичном случае использования веб-браузер получает доступ к защищенному ресурсу, аутентифицируется у своего провайдера идентификации и возвращается к ресурсу, вошедшему в систему.
1. Пользователь получает доступ к защищенному ресурсу
Пользователь пытается получить доступ к защищенному ресурсу, в результате чего SP перехватывает запрос. Расположение ресурсов для защиты может быть определено в самой конфигурации веб-сервера, например, shibd.conf, или в shibboleth2.xml (или отдельном файле) с использованием <RequestMap>.
2. SP определяет IdP и выдает запрос аутентификации
SP выберет SessionInitiator для использования на основе этой конфигурации защиты, которая, в свою очередь, отвечает за определение того, на какой IdP будет ссылаться пользователь и какой протокол использовать. Поставщики сообщают друг другу о своих профилях через обмен метаданными SAML.
Процесс определения IdP для использования называется IdP Discovery и может включать в себя комбинацию параметров конфигурации, различных веб-взаимодействий, файлов cookie и других методов. SessionInitiator может предоставить текстовое поле ввода, направить пользователя к локально или удаленно развернутой службе обнаружения (DS) или выбрать фиксированный IdP на основе запрошенного ресурса.
3. Пользователь аутентифицируется в IdP
Запрос аутентификации выдается SP IdP в результате предыдущего шага. Формат этого запроса зависит от протокола и привязки / профиля, выбранного SP. Запрос аутентификации передается через браузер, и клиент перенаправляется (через GET или POST) на конечную точку в IdP, обычно называемую «службой единого входа».
IdP анализирует запрос и решает, как он хотел бы аутентифицировать пользователя на основе правил, установленных для SP в файле relying-party.xml, и в целом для аутентификации в <LoginHandler> и login.config. Пользователь перенаправляется на выбранный обработчик входа в систему, аутентифицируется (или пытается), используя выбранный метод, и в конце концов управление переходит обратно к обработчику профиля с установленным именем пользователя.
4. IdP выпускает ответ на SP
IdP теперь использует имя участника, SP, а также протокол и привязку / профиль, выбранные, чтобы решить, какую информацию отправить SP и как ее упаковать.
Сначала IdP собирает набор атрибутов для пользователя с помощью распознавателя атрибутов. Он собирает пользовательские данные из всех внутренних источников, преобразует их при необходимости и присоединяет кодеры к каждому атрибуту.
Эти атрибуты передаются через фильтр атрибутов, который может сократить информацию, которая будет включена в ответ. Набор высвобождаемых атрибутов чаще всего зависит от SP и принципала. Это защищает конфиденциальность пользователя. Полученная информация может быть как «кто-то успешно аутентифицирован», или раскрыть любой атрибут, который вы можете себе представить.
Информация о пользователе упаковывается в форму, подходящую для возможного ответа с использованием кодеров, прикрепленных ранее, обычно в утверждении SAML. Это утверждение может быть подписано ключом IdP и, в случае подтверждения SAML 2.0, зашифровано ключом SP для обеспечения безопасности и конфиденциальности. Утверждение (или ссылка на него, называемое артефактом) помещается в ответ, который передается через клиентский браузер для доставки обратно в SP к конечной точке, называемой службой поддержки пользователей.
5. Вернуться к SP
Браузер доставляет ответ от IdP конечной точке службы поддержки пользователей в SP. Реализация ACS декодирует сообщение, расшифровывает утверждение при необходимости и выполняет различные проверки безопасности. Если все в порядке, то SP извлечет новый сеанс пользователя после извлечения атрибутов и другой информации из сообщения. Атрибуты преобразуются в кешируемую форму с использованием атрибута SP AttributeExtractor, передаются через AttributeFilter и кэшируются в новом сеансе вместе с другой соответствующей информацией.
После создания сеанса SP определяет, куда отправлять браузер, изучая информацию о «состоянии ретрансляции», возвращаемую IdP, если таковая имеется.
6. Вернуться к защищенному ресурсу
На последнем шаге браузер перенаправляется на защищенный ресурс, доступ к которому выполняется на шаге 1, но на этот раз доступ происходит в контексте сеанса, сохраненного в SessionCache SP.
Интеграция Shibboleth IDP и SP
Конфигурация SP: все файлы конфигурации Shibboleth SP находятся в каталоге SP_HOME / etc / shibboleth → / home / kuntal / Kuntal / sso / shibboleth-sp / etc / shibboleth
1. attribute-map.xml: SP переводит атрибуты, которые он получает по проводам, обычно из утверждений SAML, используя экстрактор атрибутов, обычно через файл attribute-map.xmlconfiguraton. Файл содержит ряд правил сопоставления, которые ссылаются на представление «на проводе» и связывают его с более удобным сокращением.
Листинг 2. attribute-map.xml
<Attribute name = «urn: mace: dir: attribute-def: данное имя» id = «данное имя» />
<Attribute name = «urn: mace: dir: attribute-def: uid» id = «uid» />
2. attribute-policy.xml: элемент <AttributeFilter> используется для настройки плагинов, которые фильтруют входящие атрибуты, чтобы приложения, защищенные SP, не могли видеть данные, которые нарушают любые политики, которые реализует фильтр.
Листинг 3. attribute-policy.xml
<afp: AttributeRule attributeID = «uid»>
<afp: PermitValueRule xsi: type = «ANY» />
</ Пфпи: AttributeRule>
3. shibboleth2.xml: большинство параметров конфигурации собственного поставщика услуг находится в shibboleth2.xml, расположенном в главном каталоге конфигурации SP. Основной файл конфигурации состоит из элемента <SPConfig>, который содержит один из нескольких других элементов верхнего уровня, каждый из которых представляет категорию конфигурации SP, и необязательные расширения.
Элемент <MetadataProvider> настраивает источник метаданных для использования SP. Обычно используется только в сервисе shibd.
В отличие от других файлов конфигурации, которые описывают поведение SP, метаданные, загруженные SP, описывают IdP, с которыми он хочет взаимодействовать. Каждое приложение определяет набор партнерских сайтов, которым нужно доверять, загружая их метаданные (или предоставляя для этого какой-то динамический механизм).
Листинг 4. shibboleth2.xml
<MetadataProvider type = «XML» uri = «https://shibboleth.example.org:8443/idp/shibboleth» backingFilePath = «idp92-metadata.xml» reloadInterval = «7200» />
Конфигурация IDP: Все файлы конфигурации IDP находятся в каталоге IDP_HOME / conf
/ Главная / kuntal / Kuntal / SSO / шибболет-IDP / конф
1. attribute-filter.xml: политика фильтра атрибутов описывает, какие атрибуты отправляются поставщику услуг.
Листинг 5. attribute-filter.xml
<afp: AttributeRule attributeID = «uid»>
<afp: PermitValueRule xsi: type = «basic: ANY» />
</ Пфпи: AttributeRule>
2. attribute-resolver.xml: атрибут проходит через четыре основных этапа от исходной системы к выпуску в SP: он извлекается из системы записи, массируется внутри провайдера, получает набор кодировщиков для протокола и затем фильтруется для выпуск. Каждый атрибут имеет уникальный идентификатор атрибута, который используется для последовательного обращения к нему через этот процесс.
Листинг 6. attribute-resolver.xml
<resolver: AttributeDefinition xsi: type = «ad: Simple» id = «uid» sourceAttributeID = «uid»>
<resolver: Dependency ref = «myLDAP» />
<resolver: AttributeEncoder xsi: type = «enc: SAML1String» name = «urn: mace: dir: attribute-def: uid» />
<resolver: AttributeEncoder xsi: type = «enc: SAML2String» name = «urn: oid: 0.9.2342.19200300.100.1.1» friendlyName = «uid» </ resolver: AttributeDefinition>
3. handler.xml: этот файл содержит все обработчики профиля и обработчики входа для IDP. Обработчик аутентификации поддерживает аутентификацию пользователей по имени пользователя и паролю. Эта аутентификация выполняется через Службу аутентификации и авторизации Java (JAAS).
Закомментируйте обработчик удаленного входа пользователя и раскомментируйте обработчик имени пользователя / пароля, а затем обновите его:
Листинг 7. handler.xml
<ph: LoginHandler xsi: type = «ph: UsernamePassword»
jaasConfigurationLocation = «file: ///home/kuntal/Kuntal/sso/shibboleth-idp/conf/login.config»> <ph: AuthenticationMethod> urn: oasis: names: tc: SAML: 2.0: ac: классы: PasswordProtectedTransport < / тел: AuthenticationMethod>
</ Фот: LoginHandler>
4. logging.xml: включить отладку для журналов IDP и открыть сообщения SAML
<! — Журналы IdP, OpenSAML, сообщения ->
<logger name = «edu.internet2.middleware.shibboleth» level = «DEBUG» />
<logger name = «PROTOCOL_MESSAGE» level = «DEBUG» />
5. login.config: это файл конфигурации JAAS, используемый Shibboleth IDP.
Листинг 8. login.config
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule требуется
ldapUrl = «LDAP: //kuntal.example.org: 389»
окнеРазличающееся_имя_базыполе = «OU = групп, DC = kuntal, DC = пример, DC = орг»
bindDn = «сп = kuntalganguly, НУ = групп, DC = kuntal, DC = пример, DC = орг»
bindCredential = «ldapuser»
= SSL «ложь»
userFilter = «UID = {0}»;
};
6. relying party.xml: конфигурация для связи с проверяющими сторонами. Почти во всех случаях IdP связывается с поставщиком услуг. Однако в некоторых более сложных случаях IdP может связываться с другими объектами (как и другие IdP). Конфигурация IdP использует общий термин проверяющая сторона для описания любого однорангового узла, с которым она взаимодействует. Таким образом, поставщик услуг — это просто самый распространенный тип проверяющей стороны.
IdP признает три классификации проверяющих сторон:
анонимный — проверяющая сторона, для которой у IdP нет метаданных
по умолчанию — проверяющая сторона, для которой у IdP есть метаданные, но для которой нет конкретной конфигурации
указан — проверяющая сторона, для которой у IdP есть метаданные и конкретная конфигурация
Листинг 9. relying-party.xml
<metadata: MetadataProvider id = «ShibbolethMetadata» xsi: type = «metadata: ChainingMetadataProvider»>
<! — Загрузить собственные метаданные IdP. Это необходимо для поддержки артефактов. ->
<metadata: MetadataProvider id = «IdPMD» xsi: type = «metadata: FilesystemMetadataProvider»
metadataFile = «/ home / kuntal / Kuntal / sso / shibboleth-idp / metadata / idp-metadata.xml» maxRefreshDelay = «P1D» />
<! — Загрузить метаданные SP. ->
<metadata: MetadataProvider id = «SPMD» xsi: type = «metadata: FilesystemMetadataProvider»
metadataFile = «/ главная / kuntal / Kuntal / SSO / шибболет-IDP / метаданные / зр-metadata.xml»
maxRefreshDelay = «P1D» />
7. Расположение метаданных IDP: IDP_HOME / метаданные -> / home / kuntal / Kuntal / sso / shibboleth-idp / метаданные
Внутри вы найдете файл idp-meta.xml. Но вам также необходимо поместить в нее метаданные SP.
Перейдите в своем браузере на:
Вы получите шаблон метаданных поставщика услуг по умолчанию. Переименуйте его в sp-metadata.xml и поместите его в каталог / home / kuntal / Kuntal / sso / shibboleth-idp / metadata
Теперь обновите idp-metadata.xml:
Теперь измените значение Location из тега AttributeService, ArtifactResolutionService, SingleLogoutService, SingleSignOnService.
Пример:
Предыдущий: Местоположение = «/ idp / profile / SAML2 / SOAP / SLO»
Изменено: Location = «https://kuntal.example.org:8443/idp/profile/SAML2/SOAP/SLO»
Теперь обновите sp-metadata.xml:
Теперь измените значение Location из тега ArtifactResolutionService, SingleLogoutService, AssertionConsumerService.
Предыдущий: Местоположение = «/ Shibboleth.sso / Shibboleth / SSO”
Изменено: Location = «https://kuntal.example.org/Shibboleth.sso/Shibboleth/SSO»
Развертывание приложений на сервере приложений
Захват пользовательских атрибутов из Shibboleth IDP:
Прежде чем собирать мета-атрибуты из IDP, сначала загрузите приложение A. война и ок. удалите исходный код этого учебного руководства и разверните его appServer, как упоминалось в части 1 данной учебной серии.
Из Sevlet / Jsp вы можете получить доступ к атрибутам, используя request.getAttribute (attr_name)
Но чтобы получить это значение, вы должны сделать следующее:
1. Включите префикс атрибута в файле Shibboleth SP Shibboleth2.xml в теге <ApplicationDefault> tag-> attributePrefix = «AJP_»
2. Включите модуль proxy_ajp:
прокси sudo a2enmod proxy_ajp
3. Добавьте следующее в httpd.conf
ProxyPass / appA ajp: // localhost: 8090 / appA
ProxyPass / appB ajp: // localhost: 8090 / appB
4. Затем перезапустите сервер Apache и Shibd.
sudo /etc/init.d/apache2 restart
sudo /etc/init.d/shibd restart
ИЛИ ЖЕ
Также вы можете получить информацию через заголовок.
request.getHeader ( «AJP_Shib-Идентичность-провайдер»)
Для получения значений атрибутов shibbolethes через заголовок вы должны включить заголовок внутри тега Location файла shib2.conf, как показано ниже-> ShibUseHeaders On
Настройка ресурсов приложений с помощью Shibboleth SP:
Добавьте следующее в shib2.conf для приложений Access Control.
Листинг 10. shib2.conf
<Location / appA / *>
AuthType Shibboleth
ShibRequestSetting requireSession 1
требуется действительный пользователь
</ Location>
<Location / appB / *>
AuthType Shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders On
требуется действительный пользователь
</ Location>
Примечание. Если вы хотите сделать определенное приложение доступным только для конкретного пользователя, сделайте это, как показано ниже:
Листинг 11. shib2.conf — пользовательский доступ
<Location / appA / *>
AuthType Shibboleth
ShibRequestSetting requireSession 1
требуется пользователь kganguly
</ Location>
Пользовательское поле будет пытаться получить значение из REMOTE_USER и сопоставить его с kganguly. Другой пользователь получит страницу «Отказано в доступе».
Валидация и тестирование:
Перед проведением тестирования сделайте следующее:
1. Перезапустите tomcat IDP Server и appServer (с развернутыми на нем приложениями).
2. Перезапустите сервер Apache и Shibd.
Теперь откройте браузер и перейдите по
адресу https://kuntal.example.org/appA или
https://kuntal.example.org/appB.
Он будет автоматически перенаправлен на страницу входа Shibboleth IDP, как показано ниже:
После успешной аутентификации в IDP, вы будете перенаправлены на ресурс вашего приложения и увидите экран ниже:
Тюнинг и общие проблемы
1. Тайм-аут сеанса. Тайм-аут сеанса может быть выполнен как для IDP, так и для SP.
Настройка времени ожидания сеанса SP: настройте тег Session в shibboleth2.xml.
<Время сеансов = «3600» тайм-аут = «60»>
Настройка тайм-аута сеанса IDP: настройте SessionManger в файле internal.xml на основе файлов
<bean id = «shibboleth.SessionManager»>
<constructor-arg ref = «shibboleth.StorageService» />
<constructor-arg value = «300» type = «long» />
</ Фасоль>
2. Выход из системы: чтобы применить Shibboleth Logout, используйте следующий URL /Shibboleth.sso/Logout
В этом руководстве для приложений (appA и appB)
<form action = «/ Shibboleth.sso / Logout» method = «post»>
<input type = «submit» value = «Выйти»>
3. Браузер не перенаправляет должным образом или имеет бесконечный цикл. Цикл браузера после успешной аутентификации в конце IDP происходит потому, что SP пытается создать новый сеанс и повторно отправить пользователя для аутентификации в IDP. И это продолжается в браузере как цикл.
Причина: Shibboleth SP не получает упоминание атрибута в REMOTE_USER тега <ApplicationDefaults> в shibboleth2.xml. Включите режим отладки в журналах IDP и убедитесь, что атрибут, который вы упомянули для REMOTE_USER, правильно поступает со стороны IDP через сообщение SAML. Убедитесь, что вы используете одно и то же пространство имен для атрибута в конце IDP и SP. Также кодер и декодер являются правильными как в IDP, так и в SP.
Также убедитесь, что атрибут, который вы используете в качестве NameID, имеет значение в ответе SAML. Чаще всего мы делаем переходный Id в качестве nameid, но он не имеет значения. Hence IDP устраняет его в ответе SAML. Поэтому создайте атрибут nameid, который имеет правильное значение, например, eppn или cn или (имя, как в случае с этим уроком)
<resolver: AttributeDefinition xsi: type = «ad: Simple» id = «данное имя» sourceAttributeID = «данное имя»>
<resolver: Dependency ref = «myLDAP» />
<resolver: AttributeEncoder xsi: type = «enc: SAML2StringNameID» nameFormat = «urn: oasis: names: tc: SAML: 2.0: nameid-format: unspecified» />
</ Распознаватель: AttributeDefinition>
Также убедитесь, что метаданные sp в IDP и SP обновлены. Любое несоответствие в метаданных с обеих сторон может привести к зацикливанию.
4. Нет доступной конечной точки: убедитесь, что ваш AssertionConsumerServiceURL идет от SP к IDP через запрос аутентификации saml. Это ошибка со стороны SP, но вы можете увидеть это на IDP. Отладка журнала для сообщения OpenSaml. Ответ на запрос для проверки URL-адреса службы-получателя утверждений, поступающего от SP, соответствует расположению AssertionConsumerService, указанному в файле SP metadata.xml, который использует IDP.
Вывод
В этом руководстве вы только узнаете, как легко можно разработать систему управления идентификацией на основе сигнатуры между несколькими приложениями с помощью Shibboleth Identity Provider и Service Provider. В третьей части этого руководства вы научитесь разрабатывать систему управления идентификацией с помощью CAAS.
Об авторах
Кунталь Гангули:
Инженер-программист с 4-летним опытом работы на платформе Java и Big Data. Имеет опыт использования широкого спектра продуктов с открытым исходным кодом и коммерческого продукта (Solr, Hadoop, Hbase, Hive, Pig, Storm, Spark, R, Pentaho ETL, KafkaMQ, Redis, RocksDB, OracleAQ, Weblogic). В настоящее время ассоциируется как большие данные и поисковый аналитик в ARC Document Solution Ltd.
Партха Госвами:
Инженер-программист с 4-летним опытом работы на платформе Java и Oracle Fusion Middleware. Имеет опыт использования широкого спектра инструментов с открытым исходным кодом и коммерческих инструментов (Websphere, Oracle SOA Suite, BPM, Mule ESB, RAD, Active MQ, Android, Birt и DB2). В настоящее время работает разработчиком J2EE в Cognizant Technology Solution.