На мой вопрос о уменьшение взрыва паролей, Я связался с некоторыми службами, которым мы платим деньги за доступ к их веб-сайтам, чтобы спросить, можем ли мы аутентифицировать наших собственных пользователей, и некоторые из них согласились и прислали мне спецификации о том, как это сделать. (Один из сайтов назвал такую систему страницей «порталом»; я никогда не слышал, чтобы этот термин использовался таким образом.)
Это достаточно просто, и я испытываю искушение откатать свой собственный. Самая большая сложность заключается в том, что один сайт хочет, чтобы мы хранили ключ для каждого пользователя в нашей базе данных (и я думаю, что база данных LDAP имеет смысл) после их первоначального входа в систему. Итак, нетривиально, но выполнимо.
Я полагаю, что природа такого рода задач такова, что если они начинаются с малых и простых, они так не заканчиваются. Безусловно, должно быть какое-то программное обеспечение, которое решает эту проблему и которое легко расширяется.
В своих поисках я наткнулся на:
[Вау, ну и дела. Я пропустил некоторые из них в своих предыдущих поисках! Страница Википедии на Центральные службы аутентификации полезен, а раздел о Альтернативы OpenID выглядит так, будто есть большой выбор.]
Может ли кто-нибудь порекомендовать что-либо из этого или предложить то, чего следует избегать?
Внутри мы аутентифицируемся с помощью Apple Open Directory [== OpenLDAP + Kerberos + Password Server (который, как мне кажется, == SAML)].
Что касается расширения / настройки / расширенной конфигурации системы, я могу программировать на Python, C ++, могу выполнять некоторые базовые операции PHP и, возможно, запоминать некоторые Java. Похоже, мне нужно забрать Руби в какой-то момент.
Дополнение: я также хотел бы, чтобы пользователи могли изменять свои пароли через Интернет (а для некоторых пользователей - изменять пароли других пользователей).
Мое впечатление (основанное на недавней конференции по облачным вычислениям) - это три игрока, которые "шумят" и поддерживают OpenID, SAML, и Информационные карты.
OpenID более полезен для частных лиц, его немного проще использовать / установить / что-то еще, с некоторыми компромиссами в безопасности, чтобы сделать это «проще».
SAML и информационные карты больше ориентированы на предприятия с надежной безопасностью.
Все три справляются с вашими потребностями в управлении идентификацией, но я не думаю, что OpenID вполне соответствует реальному SSO, как два других, то есть, если я вхожу на веб-сайт с помощью OpenID, он не будет автоматически входить меня на другие веб-сайты, на которых я разрешил.
SAML поддерживается Google и друзьями, поэтому, если вы используете Google Apps, Salesforce.com и т. Д., Это простой выбор. Информационные карты более или менее созданы Microsoft и (я думаю) используются MSN Live.
Существуют библиотеки OpenID и SAML на основе Python, но я еще не нашел ни одной для информационных карт (ну ладно, не особо ищу :)
Shibboleth действительно применим только для защиты доступа к ресурсам, доступным через HTTP. Он также предназначен для работы только с надежными веб-сайтами, в отличие от OpenID, который предназначен для проверки подлинности ненадежных сайтов. Я бы предположил, что OpenID значительно проще в реализации, чем Shibboleth.
Я использовал и Shibboleth, и SimpleSAML, и работал над расширениями для обоих.
В нашем офисе мы используем настроенную версию SimpleSAML php для предоставления IDP для Google Apps. Таким образом, наши сотрудники могут войти в Google Apps, используя те же учетные данные, что и в локальном офисе LDAP.
ПО МОЕМУ МНЕНИЮ:
Шибболет
SimpleSAML
В нашей идеальной настройке мы бы использовали Shibboleth SP с SimpleSAML IDP.