Единая регистрация для веб-сервисов, WCS, WFS, WMS (геосервер) и т. Д.

Question

[# вопрос отредактирован для уточнения #]

Я пытаюсь реализовать единый вход (SSO) для веб-приложения. Может быть, вы можете помочь мне найти правильное решение, дать мне направление или сказать, что решения уже существуют.

Сценарий: веб-приложение GeoExt (ExtJS для приложений на основе геоданных / карт) (только JavaScript) будет развернуто на веб-сервере клиента.

Заказчик определит «прецеденты» или «профили»: набор служб, таких как веб-службы, GeoServer WFS, WCS, Google Maps и т. Д. Для этих служб может потребоваться дополнительная аутентификация, например учетные данные или ключи.

Пользователь (который должен зарегистрироваться и подать заявку на «профиль») может (как только приложение будет предоставлено) получить учетные данные, необходимые для доступа к службам, связанным с его профилем. Как и в обычном SSO-решении, пользователю не нужно вводить каждый мандат / ключ для себя, чтобы использовать сервисы.

[# здесь без изменений ... #]

Основная проблема: я не могу изменить сторонние сервисы (например, Google), чтобы добавить механизм единого входа.

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

Другие требования: связь между приложением JS и хранилищем должна быть безопасной. Учетные данные должны храниться безопасным образом. Но приложение JS должно иметь возможность использовать их для доступа к сервисам (нет шансов надежно сохранить ключ дешифрования в приложении JS, а? * G).

[править] Прокси-сервер недоступен из-за условий использования соответствующих услуг.

Answer 1

Должен ли доступ к веб-сервисам быть в контексте пользователя или они являются общими веб-сервисами?

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

Answer 2

Мы сделали что-то похожее, используя Drupal в качестве фреймворка. http://www.drupal.org

Вы можете использовать встроенную аутентификацию Drupal или использовать решение SSO, такое как Shibboleth, вместе с модулем для него по номеру http://drupal.org/project/shib_auth или OpenID, который доступен в качестве основного модуля.

Оказавшись там, ваш мир открывается для потребления услуг многими способами, drupal_http_request или http://drupal.org/project/rest_client клиентским модулем Rest, или WSRP http://drupal.org/project/wsrp или даже shudder , как некоторые разработчики заставил нас потреблять их услуги через Iframe. Самое приятное, что уже создано множество модулей для использования существующих сервисов, таких как Gmaps http://drupal.org/project/gmap и Amazon http://drupal.org/project/amazon и т. Д.

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

Answer 3

Я думаю, что вы должны заключить в прокси / прокси каждый веб-сервис, который должен быть реализован. Это может показаться большой работой для каждого сервиса, но вы можете найти общие темы.

Подробнее: Предоставьте WS с вашего веб-сервера, который принимает идентификатор профиля пользователя, а затем фактически вызывает реальный веб-сервис с правильными учетными данными (извлекается из хранилища на стороне сервера). Таким образом, учетные данные не должны быть доступны пользователю на клиенте. Клиентскому javascript нужно всего лишь вызвать ваш сервер. И вы можете реализовать свой SSO API, обернув другие сервисы.

Внимание: дважды проверьте лицензию «добросовестного использования» для каждой веб-службы. Некоторые из них обнаружат большое количество вызовов с одного IP-адреса как нарушение соглашения об обслуживании, а затем заблокируют или внесут в черный список ваш сервер.

Answer 4

У Google уже есть пара механизмов единого входа - он поддерживает SAML, выступающий в качестве поставщика услуг (SP) (в определенных ситуациях) и OpenID, выступая в качестве поставщика удостоверений (IDP ). Вы не упоминаете, с какими сторонними сервисами вам нужно интегрироваться, но если они совместимы с любым из них, вы можете:

1. Установите SAML IDP и используйте его для единого входа в Google и другие ваши приложения
2. Используйте Google в качестве OpenID IDP (как это делает этот сайт) и используйте это для единого входа в другие приложения