Должен ли я свернуть свой собственный поставщик OpenID, или есть лучший способ? - PullRequest
2 голосов
/ 17 апреля 2011

Я разрабатываю решение для клиента, который имеет дело с довольно типичной проблемой: у них много работающих систем, каждая со своими пользователями и паролями, что приводит к ситуации, когда каждый пользователь должен запомнить три или четыре разных (или нет) логина и пароля, по одному на систему, которую им разрешено использовать. Кроме того, каждое приложение имеет свои собственные уровни аутентификации (то есть, если вы являетесь суперпользователем в одном, это не значит, что вы суперпользователь во всех из них).

Моя лучшая идея на данный момент заключается в установке поставщика OpenID и предоставлении уровней доступа с использованием расширения AX (Attribute Exchange). Это сложно, хотя, главным образом потому, что я не могу найти достойную реализацию провайдера OpenID с указанным расширением - из-за того, что я прочитал в архивах, даже Google и друзья не сделали этого правильно ...

Несколько дополнительных очков:

  • Хорошая сторона использования AX заключается в том, что доступ может управляться из центральной точки - если приложение запрашивает поле, но поставщик OpenID ничего не возвращает, то вам не разрешается входить в систему. Таким образом, опытный пользователь (он же босс, точнее его секретарь) может предоставлять / отзывать разрешения во всех системах с одной веб-страницы.
  • Я хотел бы использовать, скажем, myOpenId , но если вы когда-нибудь пытались убедить менеджера поделиться полным списком пользователей, паролей и разрешений с иностранным веб-сайтом, то вы знаете, что такие ответы я получил. Локальный сервер, хотя и, вероятно, менее безопасный, чем при использовании Google, как это ни парадоксально, является предпочтительным решением.
  • LDAP не одобряется, в основном из-за опасений, что вы можете получить полный список пользователей с соответствующим запросом (возможно, не обычные пользователи, но разработчики могут его получить). Я не эксперт по LDAP, поэтому, если вы считаете, что это верный вариант, я слушаю.
  • Да, я знаю, что sreg проще в использовании, но нет атрибута "application_access" , и в него можно добавить другое поле, например "email" , звучит немного некрасиво.

Итак, вы думаете, я здесь правильно делаю? Есть ли лучшее решение, которое я пропускаю? И если да, знаете ли вы хорошего поставщика OpenID (с расширением AX!), Который я могу установить?

1 Ответ

1 голос
/ 17 апреля 2011

С учетом требований, о которых вы говорите (администраторы могут отозвать привилегии, которые передаются через атрибуты и т. Д.), Похоже, что лучше всего использовать собственный провайдер, так как публичный провайдер с меньшей вероятностью предложить гибкость, которую вы хотите. DotNetOpenAuth имеет полную поддержку AX как для потребителя, так и для провайдера, так что было бы неплохо начать - вы также можете построить все свои настройки хранения уровня администратора и связи атрибутов поверх него. Это все еще не готовое решение (т. Е. Кодирование потребуется для «извлечения» значений AX из того места, где они хранятся), но это намного лучше, чем пытаться начинать с нуля. Много хороших примеров и сообщества, и главный автор активен в StackOverflow.

...