Есть задача — организовать межсайтовую авторизацию между проектами, размещенными на разных доменах (site1.com, site2.com). Пользователь автризовавшись на одном проекте, авторизовывается на всех (Single Sign On). Тоже самое с кнопкой выход (Single Sign Out). Доступ к хранилищу сессий и к базе есть у каждого проекта.

За два дня перелопатил множество статей и обсуждений. Вывод — стандартного решения для моего случая найти не удалось (интранет решения и сайты с четко разделенной открытой/закрытой зоной я не рассматривал).

Update: Продолжение истории Межсайтовая авторизация 2.

Это обсуждалось много и долго, напрмер в посте… Реализовал свой велосипед межсайтовой авторизации.

Итак, вернемся к задачи:
есть несколько оригинальных проектов (project1,project2,projectN...), для которых должна быть единая авторизация. То есть, Пользователь залогинившись в проекте project1 имел доступ к ресурсам project2...projectN как авторизованный пользователь.

Как правило, подобные проекты лежат на едином хостинге и желательно чтоб имели общую (единую) регистрацию. Итак, если эти условия выполняются, то нижеописанное решение может продолжить жизнь и в Вашем проекте.

Ограничение: все проекты лежат в одном датацентре и находятся в одной локальной сети. Все проекты имеют единое хранидище для сессий и соответственно единый sid.

По итогам поста, сделанного в июле 2009 и продолжительным испытаниям, мы пришли к простой и оптимальной для нас схеме межсайтовой авторизации.

На Хабре уже не раз и не два публиковались статьи о необходимости разрешить пользователю войти через Google/Twitter/Facebook и т.д. Собственно говоря, прогрессивное человечество давно решило, что требовать от пользователя придумывать логины и пароли — вчерашний день. В данной статье я хочу обсудить возникающие проблемы и способы их решения.

Одновременная межсайтовая аутентификация (SSO), для чего же она нужна? Допустим у нас есть, назовём его анахроничным термином «портал», с блогами, фотками, фейлами (или файлами, кому как), назовём его fail.ru (не путать с одноимённым сервисом почты на букву М), причём всё это усложнено следующими факторами:
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.

И вот у такого Кощея нам нужно будет сломать яйцо и дать пользователю возможность зайти только один раз, а потом заходить на все дружественные ресурсы не подтвеждая свою личность ещё раз.

Об этом уже достаточно много писали, причём и код в том числе. Но мы не пойдём по проторенной дороге велосипедостроения, а как настоящие инженеры возьмём готовые наработки и используем их. Способ прост, и подходит даже для такой сложной ситуации.

Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.

Эта статья задумывалась как практическое руководство по установке и настройке сервера JASIG CAS. Я не ставил себе целью объяснить, что такое Single Sign On (SSO), поэтому если вы еще не знакомы с этим понятием, то сначала загляните на википедию и портал Techtarget. Желательно, также иметь опыт работы со Spring и Maven.
Статья будет состоять из 3-х частей. В начале я коротко расскажу, почему мы остановили свой выбор на CAS и об особенностях его протокола. Остальная статья будет посвящена настройке сервиса авторизации, начиная с конфигурации контейнера сервлетов и заканчивая решением некоторых нетривиальных вопросов, таких как авторизация с внешней формы и хэширование учетных данных.

Приветствую, уважаемые хабро-читатели. Перед вами продолжение серии статей про JASIG CAS. В этой части я расскажу, как собрать артефакт CAS и начать с ним работать. Прежде, чем читать дальше, я надеюсь, вы прочитали первую часть.

Итак, поддавшись новомодным веяниям, малые и большие компании начинают, кто несмело, кто резво и решительно подписываться на разнообразные сервисы.

Первоначальная эйфория и «Ухты!»-эффект проходят.

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

Добрый день, хотелось бы поделиться с Вами нажитыми знаниями в этой области.
Эта статья вряд ли пригодится опытным администраторам или инженерам, во всем этом можно разобраться с помощью бинга гугла и терпения, но бывает что сроки поджимают, тема не интересна или какие-то другие обстоятельства вмешиваются в рабочий процесс. Кроме того у меня нет возможности сделать скриншоты всего и вся, потому частично они будут натыканы с веба, но процесс установки большинства компонентов сводится к тыканью кнопки далее до умопомраченья.

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

Единый вход (Single Sign-On) позволяет существующим пользователям сайта оставлять комментарии через виджет Cackle от имени учетной записи пользователя на сайте без необходимости авторизации в виджете с помощью социальной сети (OAuth) или OpenID провайдера.

Здравствуйте!

Хочу поделиться опытом установки сервера Openfire на Debian в домене AD Windows Server 2008 с использованием SSO клиентом Spark.

Сама установка проста и занимает немного времени, основные сложности для меня возникли при настройке kerberos-авторизации всей связки ПО.

Инфраструктура:
Openfire 3.8.2 устанавливаем на Debian 7.0 «Wheezy» x64 с использованием СУБД MySQL.
Имя Debian-сервера: openfireserver.
Служба Active Directory развернута на Windows 2008 Server Standard (Kerberos использует шифрование RC4-HMAC-NT по умолчанию).
Домен realm.local.
Рабочие станции Windows XP Pro и Windows 7 Pro x32/x64 с установленным клиентом Spark 2.6.3.

Аутентификация пользователей в экосистемах наподобие Google или Envato реализована в виде отдельных сервисов (accounts.google.com, account.envato.com), предоставляющих необходимые данные и токены сайтам-клиентам. В ходе разработки некоторых проектов на Ruby on Rails мне и пришлось столкнуться с подобной задачей. По-научному — single sign-on или технология единого входа.

Нужен был (1) общий сервис для всех сайтов экосистемы, с (2) преимущественно социальной авторизацией, в угоду входу по связке «логин+пароль».
Сервис, (3) аккумулирующий в себе данные из тех социальных сервисов, с помощью которых пользователь входит в систему, и (4) предоставляющий эти данные сайтам-клиентам.

Задача оказалась настолько же интересной, насколько и нестандартной. Началось все с полезной, но уже немного устаревшей статьи — автор предлагал использовать гем omniauth и кастомную стратегию на сайтах клиентах, а на сайте-провайдере — использовать тот же omniauth в связке с devise для аутентификации через соц. сервисы.

Devise в моем случае подходил мало (завязка на логине+пароле), поэтому предпочтение было полностью отдано omniauth. С этого и началось мое маленькое приключение, о ходе которого предлагаю вам ознакомиться в данной статье.

1. Предыстория

Не смотря на то, что функция централизованного входа (Single Sign On, SSO) существует, обсуждается и применяется уже давно, на практике ее внедрение зачастую сопровождается преодолением самых различных проблем. Целью данной статьи будет показать, как реализовать простейший собственный Service Provider ¹ (SP) для SAML 2.0 identity provider (idP) и с его помощью осуществить интеграции SSO в Java Web приложение.

Одним из наших последних проектов была подготовка и кластеризация портального решения для крупного университета. В рамках проекта мы столкнулись с задачей реализации (а также кластеризации) функции единой аутентификации для следующих систем:

1. Liferay version 6.1.20-ee-ga2.
2. Простое java web-приложение.
3. Google apps.

Со стороны заказчика были выдвинуты основные требования построения SSO:

1. Для построения SSO должен использоваться протокол SAML 2.0.
2. Требуется интеграция с Jasig CAS для поддержания работы уже существующих систем.
3. LDAP используется для проверки аутентификации пользователей.

В качестве idP решили использовать Shibboleth (http://shibboleth.net/about/index.html) как open source-систему, реализующую в полном объеме протоколы SAML 1.0 && SAML 2.0.

Сложные моменты, с которыми мы столкнулись при решении данной задачи:

1. Отсутствие экспертизы по работе с протоколом SAML 2.0 и продуктом Shibboleth.
2. Сырая и еще не достаточно хорошо структурированная документация по Shibboleth от производителя.
3. Отсутствие качественных примеров по реализации Service Provider’а для интеграции SSO в свое Java Web-приложение.

Преодоление этих барьеров и стало мотивацией для публикации данной статьи. Мы хотим поделиться приобретенными знаниями, помочь разработчикам решать подобные задачи, а также облегчить знакомство с протоколом SAML 2.0.

2. Для кого предназначена статья?

Данная статья ориентирована на следующую аудиторию:

1. Разработчики, интегрирующие функцию SSO в своих проектах средствами SAML 2.0.
2. Java-Разработчики, которым нужен практический пример интеграции в свое приложение функции SSO средствами SAML 2.0.
3. Java-Разработчики, которые хотят опробовать в качестве SSO Identity Provider’а (idP) компонент Shibboleth.

Для понимания статьи рекомендуется иметь минимальные знания по протоколу SAML 2.0.

Статья будет интересна всем, кто хочет узнать значение страшного термина «Active Directory Federation Services» на примере из реальной жизни, а также всем, кто занимается разработкой кастомных систем на базе SharePoint и находится в процессе принятия решения, какую модель авторизации и аутентификации выбрать, либо собирается переключить существующее решение на ADFS.

А самое главное, она пригодится тем, кому важны потребительские качества IT-продукта, его значение и удобство для конечного пользователя.

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

Это система лояльности для кассиров, которые продают услуги нашего заказчика. Выполнена на MS SharePoint. Через портал кассиры копят бонусы и получают за них подарки (сувенирку, турпутевки, подарочные карты и т.п.) Компания таким образом может гибко управлять продажами нужных «позиций», анализировать работу кассиров и агентств и много еще чего полезного.

Мы разрабатывали программу лояльности с самого начала. Первый релиз состоялся в феврале 2013 года. Развитие системы продолжается. Например, только что мы провели полный редизайн портала. Но этому предшествовала миграция на ADFS, как важнейший этап модернизации. Об этом — дальше речь.

Мы уже подняли сервер Jasig CAS теперь пора немного его кастомизировать. Зачем это нужно? Сейчас ми авторизируемся используя статического пользователя, но мы это исправим и сделаем возможность получать пользователя из внешних систем или БД.

Представьте, что у вас есть web-проект, который состоит из двух или более частей, (part1.example.com) и вторая часть (part2.example.com). Теперь перед вам стоит задача сделать Аутентификацию пользователя, но так чтобы когда пользователь зайдя один раз в любую из частей web-проекта, например, в первую, то во второй он уже должен быть аутентифицирован.

Сегодняшний пост будет про удобство использования Redmine в корпоративной среде, а если быть точнее, про прозрачную авторизацию пользователей Redmine в домене Microsoft Active Directory.

Мы используем Redmine как единую информационную среду, в которой работают все сотрудники компании. Вводить один и тот же пароль дважды — это всегда неудобно. Поэтому, мы настроили прозрачную аутентификацию через домен.

Пост расcчитан на новичков, которые только знакомятся с SSO. В интернете не очень много документации по связке OpenAM и mod_auth_mellon, тем более на русском языке.
Для быстрого старта буду использовать образы Docker. Для аутентификации пользователя рассмотрю модуль mod_auth_mellon, но можно использовать и другие методы, к примеру Policy Agent или OpenIG.

Теория

Технология единого входа (англ. Single Sign-On) — технология, при использовании которой пользователь переходит из одного раздела портала в другой без повторной аутентификации.
OpenAM (Access Management) — провайдер идентификации (IdP, англ. identity provider), осуществляет аутентификацию пользователя.
mod_auth_mellon — модуль apache, который аутентифицирует пользователя через IdP (OpenAM).