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

Question

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

Ключевое слово параметрических усилителей, т.е.

public void DoSomething(params string[] theStrings)
{
  foreach(string s in theStrings)
  {
    // Something with the Strings…
  }
}

Названный как

DoSomething(“The”, “cat”, “sat”, “on”, “the” ,”mat”);

6

web-services security authentication cross-platform authorization

задан tsbnunes 21 July 2009 в 19:57

3 ответа

Другие вопросы по тегам:

web-services security authentication cross-platform authorization

Похожие вопросы:

score 2 · Answer 1

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

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

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

score 0 · Answer 2

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

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

0

ответ дан 17 December 2019 в 07:07

score 2 · Answer 3

Эта проблема в значительной степени решена с помощью 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 есть реализации, которые могут быть полезны.