Централизованная аутентификация и авторизация для нескольких веб-сервисов

Question

Существует несколько различных веб-сервисов - используются разные технологии, такие как Java, .NET, Python, Perl и, возможно, в будущем - принадлежащие различным организациям, и доступ к этим веб-сервисам должен быть ограничен. .

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

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

Требования безопасности высоки, поэтому недостаточно ввести имя пользователя / пароль.

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

Answer 1

Мы провели большое исследование по этому вопросу и не смогли найти подходящего решения. (Одно почти хорошее решение, но не очень для веб-сервисов: http://www.atlassian.com/software/crowd/)

Таким образом, мы также разработали систему управления пользователями и центральным пользователем для наших приложений WS (также сторонних приложений), но она не продается.

Если вы тестируете решения, вы должны проверить производительность систем, особенно под нагрузкой. В начале наши системы были в 30 раз медленнее. Обычно вы найдете замедление в разборе xml и количество запросов, которые вам нужно сделать (обычно там, где у вас был один запрос в будущем, у вас будет как минимум 4). (Мы используем jmeter для тестирования.) И вам нужно настроить отказоустойчивость систем, потому что вы создадите единственную точку отказа с помощью sso.

Answer 2

Эта проблема была в значительной степени решена WS-Trust, по крайней мере для веб-сервисов на основе SOAP. WS-Trust - это четко определенный протокол для проверки и обмена «токенами аутентификации», который может использоваться в сценариях между предприятиями с такими протоколами, как WS-Federation.

Один из примеров: клиенты запрашивают токен с сервера WS-Trust, а затем включают этот токен в заголовок SOAP хосту веб-службы. С другой стороны, нужно включить в запрос к хосту что-то простое, например , и иметь аутентификацию делегата на стороне сервера для сервера WS-Trust.

Существует довольно хорошая поддержка клиентов для WS-Trust - WCF имеет встроенную поддержку, а у разных поставщиков есть перехватчики J2EE для веб-служб JAX-RPC и JAX-WS.

Пока WS-Trust фокусируется на аутентификации, вы можете выполнить грубую авторизацию, используя логику о том, когда выдавать или проверять полученный токен. Не выдавайте / проверяйте токен, и доступ фактически запрещен. Для детальной авторизации для веб-сервисов обычно требуются пользовательские перехватчики, которые зависят от поставщика.

Я работаю в IBM Tivoli Security, и у нас есть несколько продуктов в этом пространстве. Первый - Tivoli Federated Identity Manager (TFIM). Мой коллега и я написали эту статью об интеграции TFIM с веб-сервисами на основе WSE и содержат обзор самого протокола WS-Trust. Второй продукт - Tivoli Security Policy Manager (TSPM), который реализует детализированную авторизацию для веб-сервисов.

Существуют реализации этих же протоколов с открытым исходным кодом, что является преимуществом использования основанного на стандартах решения. Я считаю, что у JBoss и WSO есть реализации, которые могут быть полезны.

Answer 3

Разве не для этого нужен OpenID?

Обязательно поправьте меня, если я ошибаюсь.