Использование SAML / OpenID Connect для реализации единого входа для двух веб-сайтов. Как аутентифицировать клиента Swing?

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

Я читал о неявном потоке OpenID Connect, но, похоже, ему все еще нужно открыть браузер.

Профиль расширенного клиента или прокси SAML, который, кажется, решает эту проблему, похоже, не реализован большинством idps, с которыми я пробовал. (Только Shibboleth поддерживает его, а документация для Shibboleth не так хороша).

  • Какое решение подходит для этой проблемы?
  • Существуют ли другие механизмы единого входа, поддерживающие как собственные, так и веб-приложения?
  • Есть ли обходные пути для OpenID Connect / SAML для такого рода проблем?
  • Было бы неплохо просто предоставить REST API, который аутентифицирует клиента Swing, используя те же учетные данные, что и SSO IdP?

native openid-connect saml single-sign-on
person Can't Tell    schedule 26.05.2015    source источник
comment
Создайте простой пользовательский токен для аутентификации: thebuzzmedia.com /   -  person lcryder    schedule 26.05.2015
comment
Настольное приложение, о котором вы говорите, управляется той же компанией, что и поставщик удостоверений, верно? Другими словами: контролируете ли вы кодовую базу поставщика удостоверений И настольное приложение?   -  person Michael Técourt    schedule 31.07.2015
comment
@MichaelakoTecourt да   -  person Can't Tell    schedule 31.07.2015

Ответы (1)


arrow_upward
2
arrow_downward

OpenID Connect пытается решить проблему совместного использования аутентификации пользователя между двумя сторонами: поставщиком удостоверений (OP) и клиентом.

Это четко не указано в документации OIDC, но, исходя из моего опыта, OIDC не пытается решить, как вы аутентифицируете своих пользователей на разных платформах (веб, мобильные / настольные).

Это один из немногих допустимых вариантов использования OAuth 2.0 "Предоставление учетных данных для пароля владельца ресурса", где клиент обменивает учетные данные пользователя на токен.

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

РЕДАКТИРОВАТЬ: экземпляры мобильного приложения могут совместно использовать (если вам не удается динамически назначать идентификаторы клиентов) идентификатор / секрет клиента, который нельзя сохранить в тайне. Он составляет действительно тонкий уровень аутентификации клиента, пытаясь убедиться, что что запросы поступают из вашего мобильного / настольного приложения:

POST /oauth/token HTTP/1.1
Authorization: Basic ${BASE64_ENCODED_CLIENTID_CLIENTSECRET}
  grant_type=password&
  username=${USERNAME}&
  password=${PASSWORD}

Некоторым людям не нравится, что в нем указывается способ аутентификации пользователя, а некоторые компании могут иметь дополнительные учетные данные, кроме имени пользователя и пароля, например, при использовании двухфакторной аутентификации. Кроме того, некоторые люди неправильно использовали грант ROPC, поскольку он действителен только внутри организации, позволяя клиенту запрашивать ваши собственные учетные данные, убивая точку наличия протокола SSO / авторизации.

OIDC по-прежнему OAuth 2.0, что означает, что вы можете реализовать собственный поток «учетных данных пользователя» для получения токена доступа + токена идентификатора из своего настольного / мобильного приложения. Однако это выходит за рамки OIDC.

Между прочим, SAML был создан в то время, когда мобильные приложения еще не использовались:

SAML 2.0 был ратифицирован в качестве стандарта OASIS в марте 2005 г.

person Michael Técourt    schedule 31.07.2015