Кроссплатформенный SSO - с чего начать? - PullRequest
Новая
       74

Кроссплатформенный SSO - с чего начать?

5 голосов
/ 03 апреля 2012

Я изучаю варианты единого входа в систему между двумя разнородными системами: одна .NET, одна Java EE.Каждый из них управляется независимо и имеет отдельное управление пользователями, с некоторыми пересекающимися пользователями.

Я хотел бы иметь возможность связывать друг с другом без повторного запроса пароля.

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

Что бы вы порекомендовали, с точки зрения подхода и / илипродукт (желательно с открытым исходным кодом)?

Во-первых, хотите ли вы использовать что-нибудь, поддерживающее SAML, OpenID, OAuth или ничего из вышеперечисленного?

Во-вторых, я знаю, что есть бесплатные продукты с открытым исходным кодом.OpenAM, Shibboleth, JOSSO и CAS.Есть какой-нибудь опыт, которым можно поделиться с кем-либо из них, хорошим, плохим или уродливым?

1 Ответ

9 голосов
/ 19 апреля 2012

Сначала рассмотрим протоколы:

  1. SAML 2.0 - это централизованный / децентрализованный протокол единого входа.Это самый продвинутый протокол и предлагает федерацию, т. Е. Вы можете позволить пользователям входить в систему с использованием любой из систем X или направлять всех пользователей через единую систему (известную как IDP).SAML 2.0 широко используется в финансовом и государственном секторах наряду с некоторыми основными размещенными приложениями (например, приложения Google и Saleforce).Это также самый сложный протокол

  2. OpenID - это децентрализованный протокол, который больше всего подходит для Интернета, а не для приложений интрасети / экстрасети.Пользователи могут выбрать для входа любого провайдера OpenId.Stackoverflow - хороший пример OpenId - мы можем войти в систему, используя нашу учетную запись Google или Facebook.Вы можете реализовать OpenId централизованным способом, принудительно установив связь по умолчанию между потребляющим приложением (известным как проверяющая сторона) и системой единого входа (известным как поставщик услуг).

  3. OAuth на самом деле не протокол SSO.Это позволяет пользователю предоставлять Приложению A доступ к своей информации в Приложении B, не предоставляя учетные данные для Приложения B к Приложению A. Некоторые люди использовали OAuth как форму псевдо-аутентификации, т.е. если система способна получить доступ к фотографиям, принадлежащим Пользователю Xтогда пользователь должен быть X. Это взлом и не рекомендуется.

Это определенно хорошая идея использовать стандартизированный протокол, чтобы избежать блокировки. Microsoft недавно представила поддержку SAML2.0 и есть много открытых и коммерческих продуктов, доступных для Java.Существуют реализации OpenId для java, но я не знаю достаточно о мире .NET, чтобы комментировать.

Как вы упомянули, существует целый ряд продуктов SAML с открытым исходным кодом (OpenAM, Shibboleth, JOSSO и CAS),Одно предостережение: SAML - сложный протокол, поэтому, если вы пойдете по пути с открытым исходным кодом, вам нужно будет подготовиться к тяжелой работе.Когда мы создавали нашу Cloudseal SSO платформу (на основе SAML 2.0), мы потратили много времени, пытаясь упростить вещи, чтобы абстрагировать их от сложности.Другие коммерческие поставщики сделали то же самое, но продукты с открытым исходным кодом, которые вы упомянули, больше ориентированы на функциональность, чем на простоту - ИМХО!:)

...