Единый вход для полнофункциональных клиентов (толстых клиентов) без входа в Windows

единый вход (SSO) для веб-приложений (используемый через браузер) хорошо задокументирован и установлен. Установить SSO для полнофункциональных клиентов сложнее, и обычно предлагается на основе билетов Kerberos, в частности, с использованием входа Windows в ActiveDirectory в домене.

Однако я ищу более общее решение для следующего: мне нужно установить "настоящий" SSO (один идентификатор для всех приложений, т.е. не просто синхронизация паролей между приложениями), где на стороне клиента (неуправляемые компьютеры, в т.ч. не-Windows), «конечными клиентами» являются приложение Java и приложение GTK+. Оба взаимодействуют со своими серверными аналогами, используя протокол на основе HTTP (скажем, WebServices через HTTPS). Клиенты и сервер не обязательно находятся в одной и той же локальной сети или интрасети, но клиент может получить доступ к серверам из экстрасети. Серверная часть всех приложений находится в одной и той же сетевой области, и компонент SSO может получить доступ к поставщику удостоверений через LDAP.

Мой вопрос в основном "как я могу это сделать"? В частности,

а) существует ли согласованный механизм безопасного и защищенного «хранилища сеансов SSO» на стороне клиента, как в случае с файлами cookie SSO для приложений, доступ к которым осуществляется через браузер? Возможно, что-то вроде эмуляции Kerberos (TGT?) или даже прямого повторного использования его, даже если на стороне клиента не выполнялась аутентификация ActiveDirectory?

б) существуют ли какие-либо протоколы/API/фреймворки для связи между богатыми клиентами и другими участниками SSO (как в случае с файлами cookie)?

c) существуют ли какие-либо API/фреймворки для передачи TGT и сеансовых билетов, подобных kerberos, по сети?

d) есть ли какие-либо примеры реализации/учебники, демонстрирующие, как выполнять SSO для полнофункционального клиента?

Я так понимаю, что есть "заполняющие" агенты, которые учатся вводить учетные данные в диалоги приложения на стороне клиента. Я бы предпочел не использовать такого «помощника», если это возможно.

Также, если возможно, я хотел бы использовать CAS, Shibboleth и другие компоненты с открытым исходным кодом, где это возможно.

Спасибо за комментарии, предложения и ответы!

МиКу


saml single-sign-on kerberos fat-client
person MiKu    schedule 18.08.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Переход с учетной записью AD ЯВЛЯЕТСЯ универсальным решением. Kerberos вездесущ. Это единственный механизм, который будет запрашивать ваши учетные данные один раз и только один раз при входе в систему.

Это все осуществимо, вам нужно:

  1. KDC
  2. Правильные записи DNS
  3. учетные записи KDC
  4. Правильные записи SPN
  5. Клиентские компьютеры, настроенные для связи с KDC
  6. Приложение Java, использующее JAAS с JGSS для получения билетов на обслуживание
  7. GSS-API с вашим приложением GTK+ для получения сервисных билетов

Что ты уже понял сам?

person Michael-O    schedule 18.08.2012
comment
Спасибо, Майкл-О, это звучит хорошо, если клиентский компьютер имеет учетную запись ActiveDirectory (т. е. когда вход в систему создает билет Kerberos), но я также хочу охватить клиентов, для которых это не так. Другими словами, я не хочу делать никаких предположений о клиенте, но я хочу получить и поделиться TGT (например, билетом Kerberos) надежным способом. Допустимо, если это делается способом, зависящим от платформы, поскольку доступ к хранилищу Kerberos может осуществляться по-разному. Любые способы/методы/API для этого? - person MiKu; 19.08.2012
comment
Вы находитесь в управляемой среде интрасети или в Интернете? - person Michael-O; 19.08.2012
comment
Все управляемые клиенты имеют билет Kerberos. Но мне нужно учитывать клиентов, у которых есть VPN-доступ в сеть, и поэтому они не управляются и не обязательно Windows. - person MiKu; 19.08.2012
comment
Ну, я не знаю, как выглядит ваш протокол связи, но вы можете указать несколько вариантов аутентификации: GSS-API => Basic/Digest. Первый будет для пользователей домена, второй будет проверять по базе данных. Если вы примените эту схему к HTTP, это будет просто означать: WWW-Authenticate: Negotiate и WWW-Authenticate: Basic. - person Michael-O; 19.08.2012

arrow_upward
0
arrow_downward

Согласен с Майклом, что вы хотите использовать GSSAPI/Kerberos. Добавлю, однако, что с Java есть загвоздка: по умолчанию JGSS использует собственные реализации GSSAPI и Kerberos, написанные на Java в JDK, а не библиотеки платформы. Таким образом, он не подчиняется вашей существующей конфигурации и не работает как что-либо еще (например, в Unix он не учитывает KRB5CCNAME или другие переменные среды, к которым вы привыкли, не может использовать DNS для обнаружения KDC, имеет другой набор поддерживаемых шифров и т. д.). Это также глючит и ограничено; например, он не может следовать рефералам.

На платформах Unix вы можете указать JGSS обойти код JDK и использовать внешнюю библиотеку GSSAPI, запустив JVM с помощью:

-Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/libgssapi_krb5.so

Однако в Windows нет аналогичной опции для использования SSPI. Это выглядит многообещающе:

http://dblock.github.com/waffle/

... но я еще не дошел до решения этой проблемы.

person Richard E. Silverman    schedule 22.08.2012