Comments 32
Разве OAuth (по крайней мере для facebook'а) не работает точно также как вы описали в сценарии для CAS? Если у нас пользователь не авторизован, то редиректим к facebook'у. Тот либо распознает свои куки, либо спрашивает login/pass. Затем уже с токеном редиректит назад к нам. Мы токен проверяем у фейсбука и открываем для юзера сессию. У себя в проектах использовал, работало.
Хотя опять же зависит от сервиса, у кого авторизуемся. Может кто и спрашивает постоянно login/pass при каждом обращении, не знаю.
Хотя опять же зависит от сервиса, у кого авторизуемся. Может кто и спрашивает постоянно login/pass при каждом обращении, не знаю.
+7
Очевидно, проблема в том, что для каждого сайта из группы пользователю придётся прогулятся на фейсбук и подтвердить авторизацию, а в данном варианте после первой авторизации на любом сайте из группы, можно заходить на остальные без дополнительных телодвижений.
-1
в случае использования CAS вам всё равно при первой попытке авторизации с каждого сайта придётся прогуляться на сервер CAS.
по сути плюс его использования относительно OAuth только в том, что OAuth будет спрашивать разрешения пользователя передать токен сайту для каждого из них, а CAS спрашивать не будет, и будет сразу передавать.
самое тупое решение, приходящее в голову — свой OAuth-провайдер, который не будет спрашивать ничего у пользователя с доверенных сайтов. итого: CAS — велосипед.
по сути плюс его использования относительно OAuth только в том, что OAuth будет спрашивать разрешения пользователя передать токен сайту для каждого из них, а CAS спрашивать не будет, и будет сразу передавать.
самое тупое решение, приходящее в голову — свой OAuth-провайдер, который не будет спрашивать ничего у пользователя с доверенных сайтов. итого: CAS — велосипед.
+6
Наверное есть разница, один раз запрашивать авторизацию для 10 сайтов, или 10 раз для каждого сайта?
0
А, неправильно прочитал ваш коммент, теперь понятно.
0
OAuth-провайдер, который ничего не спрашивает и уже залогиненных пользователей, — это OpenID.
-1
вы заблуждаетесь. спрашивать или нет — тоже зависит исключительно от OpenID-провайдера. а OpenID и OAuth — два разных протокола.
0
Я имею в виду, что OAuth что-то спрашивает как раз потому, что это протокол авторизации. И то, что он спрашивает, — это разрешение пользователя на доступ к определенным операциям, предоставляемым сервисом.
А если сервис ничего не спрашивает в плане авторизации, то никакой авторизации нет, и остаётся только аутентификация, с которой прекрасно справляется OpenID.
То есть, в описанном случае OAuth не нужен, а достаточно только OpenID — для того, чтобы аутентифицировать пользователя.
А если сервис ничего не спрашивает в плане авторизации, то никакой авторизации нет, и остаётся только аутентификация, с которой прекрасно справляется OpenID.
То есть, в описанном случае OAuth не нужен, а достаточно только OpenID — для того, чтобы аутентифицировать пользователя.
0
в первую очередь OAuth и OpenID выполняют одну и ту же роль: подтверждают стороннему ресурсу, что посетитель является зарегистрированным пользователем провайдера с определённым идентификатором.
доступ к операциям сервиса является вторичной и необязательной функцией OAuth-провайдеров.
доступ к операциям сервиса является вторичной и необязательной функцией OAuth-провайдеров.
-2
Это распространённая ошибка — считать, что у OAuth и OpenID одна и та же роль.
OpenID предназначен для аутентификации, а OAuth — для авторизации.
К аутентификации OAuth плохо приспособлен. Хотя с его помощью и можно осуществлять псевдо-аутентификацию, но это отнюдь не использование по его прямому назначению.
OpenID предназначен для аутентификации, а OAuth — для авторизации.
К аутентификации OAuth плохо приспособлен. Хотя с его помощью и можно осуществлять псевдо-аутентификацию, но это отнюдь не использование по его прямому назначению.
-1
это распространённая ошибка говорить кому-то про распространённые ошибки без каких-либо пруфлинков.
псевдо-аутентификация, или не псевдо, с точки зрения чёрного ящика, они выполняют одну и ту же функцию: предоставляют креденшиалы (будь то токен, или логин-имейл), доверяемые на основании условного доверия к провайдеру.
псевдо-аутентификация, или не псевдо, с точки зрения чёрного ящика, они выполняют одну и ту же функцию: предоставляют креденшиалы (будь то токен, или логин-имейл), доверяемые на основании условного доверия к провайдеру.
-1
Например, вот здесь, в первом ответе, неплохо описано, почему стоит хорошо подумать, прежде чем использовать OAuth для аутентификации.
В этой статье разница между двумя протоколами описана больше с концептуальной точки зрения. Прочитав её, я думаю, вы поймёте, почему я сказал, что у OpenID и OAuth разные роли, и что в описанном вами случае достаточно OpenID.
В этой статье разница между двумя протоколами описана больше с концептуальной точки зрения. Прочитав её, я думаю, вы поймёте, почему я сказал, что у OpenID и OAuth разные роли, и что в описанном вами случае достаточно OpenID.
0
я не понимаю, что вы мне пытаетесь доказать. я прекрасно знаю, что OAuth отдаёт приложению не фактические креденшиалы, а токен доступа к функциям сервиса. но это лишь говорит о том, что функции OAuth шире функций OpenID, а не отличны от них.
и это лишь теория. на практике, к примеру, фейсбук отдаёт токен, в котором ключём приложения зашифрованы креденшиалы (айди, юзернейм) пользователя.
и если вернуться к началу спора, вы сказали: «OAuth-провайдер, который ничего не спрашивает и уже залогиненных пользователей, — это OpenID». попробуйте воспользоваться любым открытым OpenID
и это лишь теория. на практике, к примеру, фейсбук отдаёт токен, в котором ключём приложения зашифрованы креденшиалы (айди, юзернейм) пользователя.
и если вернуться к началу спора, вы сказали: «OAuth-провайдер, который ничего не спрашивает и уже залогиненных пользователей, — это OpenID». попробуйте воспользоваться любым открытым OpenID
0
попробуйте воспользоваться любым открытым OpenID провайдером. он спросит: «хотите авторизовать сайт такой-то»?
0
В токене фейсбука ничего не зашифровано, и расшифровке токен не поддаётся, потому что является случайно сгенерированным уникальным идентификатором, которому в соответствие поставлен id пользователя и приложения в БД фейсбука.
В теории OAuth и OpenID вещи очень разные, но по факту они могут использоваться для аутентификации совершенно на равных условиях (когда аутентифицирующий сайт не требует никакой информации о клиенте, кроме, скажем, идентификатора пользователя, чего вполне достаточно).
Авторизация — дело третье, и в этом топике я вообще этого вопроса не касался.
После написания топика много думал, и понял, что действительно, для нужн аутентификации и CAS и OpenID, и OAuth отлично подходят.
Да, для получения доп. информации о клиенте лучше подходит OAuth, но CAS провайдер может задавать те же самые вопросы, и точно так же передавать дополнительную информацию о клиенте (но не давать делать вызовы API от имени клиента, это не предусмотрено). Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
Вообще, OpenID и OAuth идут в одном и том же направлении в последнее время, пытаясь угодить всем сложным вариантам использования. Думаю, нужно запастись попкорном.
Хотел написать интересный топик про аутентификацию и авторизацию сайтов с помощью Facebook и Вконтакте, но у первого так всё просто, а у второго так всё плохо, что на топик даже не тянет.
В теории OAuth и OpenID вещи очень разные, но по факту они могут использоваться для аутентификации совершенно на равных условиях (когда аутентифицирующий сайт не требует никакой информации о клиенте, кроме, скажем, идентификатора пользователя, чего вполне достаточно).
Авторизация — дело третье, и в этом топике я вообще этого вопроса не касался.
После написания топика много думал, и понял, что действительно, для нужн аутентификации и CAS и OpenID, и OAuth отлично подходят.
Да, для получения доп. информации о клиенте лучше подходит OAuth, но CAS провайдер может задавать те же самые вопросы, и точно так же передавать дополнительную информацию о клиенте (но не давать делать вызовы API от имени клиента, это не предусмотрено). Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
Вообще, OpenID и OAuth идут в одном и том же направлении в последнее время, пытаясь угодить всем сложным вариантам использования. Думаю, нужно запастись попкорном.
Хотел написать интересный топик про аутентификацию и авторизацию сайтов с помощью Facebook и Вконтакте, но у первого так всё просто, а у второго так всё плохо, что на топик даже не тянет.
0
токен у фейсбука состоит из двух частей.
developers.facebook.com/docs/authentication/signed_request/
> Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
а смысл для какого-то левого CAS?
> у второго так всё плохо, что на топик даже не тянет.
ещё год назад писал для него адаптер авторизации. через JS API всё тривиально, через oauth2 всё, как у всех.
developers.facebook.com/docs/authentication/signed_request/
> Можно схожий функционал сделать и для OpenID, но смысла в этом нет.
а смысл для какого-то левого CAS?
> у второго так всё плохо, что на топик даже не тянет.
ещё год назад писал для него адаптер авторизации. через JS API всё тривиально, через oauth2 всё, как у всех.
0
Произошла подмена понятий. signed_request передаётся в редких случаях, а я имел в виду полноценный access_token.
+1
CAS — и протокол, и готовый продукт, с готовой интеграцией с хранилищами пользователей, несложный в установке, настройке и поддержке. Протокол да, ничего особенного, но работает вполне так, как от него этого ожидают.
И несмотря на то, что OpenID провайдеры из коробки не умеют SSO, и это легко устранимо, это означает то, что требуется доработка. А вы, конечно, понимаете, что доработка, особенно готового продукта в рамках разработки корпоративных и государственных продуктов сулит составление пакета отдельного пакета документации на подсистему. Поверьте, вы этого не хотите. Проще косвенно упомянуть его в паре руководств. Добавьте к этому юридический аспект (использование доработанного стороннего продукта в рамках комплексной системы), и выбор в сторону CAS становится очевидным.
И несмотря на то, что OpenID провайдеры из коробки не умеют SSO, и это легко устранимо, это означает то, что требуется доработка. А вы, конечно, понимаете, что доработка, особенно готового продукта в рамках разработки корпоративных и государственных продуктов сулит составление пакета отдельного пакета документации на подсистему. Поверьте, вы этого не хотите. Проще косвенно упомянуть его в паре руководств. Добавьте к этому юридический аспект (использование доработанного стороннего продукта в рамках комплексной системы), и выбор в сторону CAS становится очевидным.
+1
Интересная статья.
Есть еще разрабатываемый командой Identity Team из Mozilla Labs — browserid.
Хотелось бы почитать мнения и о нем. Ибо не встречал на хабре ничего об этом.
Есть еще разрабатываемый командой Identity Team из Mozilla Labs — browserid.
Хотелось бы почитать мнения и о нем. Ибо не встречал на хабре ничего об этом.
+1
Правильно ли я понимаю, что примерно так работает login.webmoney.com?
-3
1) Насколько я знаю, CAS-сервер не должен делать автоматического перенаправления назад на сайт (если cookie уже есть), а всё равно должен спросить согласие пользователя. Т. е. вход получается непрозрачный (надо делать дополнительный клик и будет виден интерфейс CAS-сервера). Можно конечно это правило проигнорировать в своей реализации… Я в своей реализации на drupal это пробовал делать, но в итоге отключил.
2) Если на сайте должен быть предусмотрен и анонимный просмотр, тогда переход на CAS-аутентификацию должен быть по запросу (при клике «войти»). Опять же не прозрачно, надо кликать, потом опять кликать подтверждение.
2) Если на сайте должен быть предусмотрен и анонимный просмотр, тогда переход на CAS-аутентификацию должен быть по запросу (при клике «войти»). Опять же не прозрачно, надо кликать, потом опять кликать подтверждение.
0
Поправьте, пожалуйста:
- «Критка и мифы» → Критика
- «cайтом, на которым вы хотите аутентифицироваться» → котором
- «с испольованием разных технологий» → использованием
- «не подтвеждая свою личность» → подтверждая
- «подтвеждение через ссылку» → подтверждение
- «вопросы хранения аутенитификационных данных» → аутентификационных
- «Можно испльзовать вариант» → использовать
0
Если уж говорить о собственном сервере для SSO, то в этом случае недостаток, который вы указали для OpenID, легко устраним. И для проекта, которым я в данный момент занимаюсь, я выбрал для SSO именно собственный провайдер OpenID. Кроме простого SSO с использованием логин/пароля мне от провайдера требовался ещё и дополнительный функционал (аутентификация через соц. сети и др. OpenID/oAuth провайдеры, личный кабинет, внутренний API с авторизацией через oAuth и т.д.). Поэтому тот факт, что полноценная реализация CAS провайдера есть только на языках, которые в данный момент не являются моими фаворитами оказался существенным минусом для этого протокола.
0
При входе на целевой сайт вас отправят на coolopenid.net, там либо посмотрят cookie, если вы уже залогинены, либо спросят емейл и пароль, вы подтвердите свою личность, и далее входите на целевой сайт, как, например, foo1@coolopenid.net. Правда, не намного проще, чем подтвеждение через ссылку на электронную почту?Не, ну критика должна быть обоснованной. Пользователь освобождается от необходимости запоминать пароли на толпах сайтов и регистрироваться на них, даже если ему этот сайт требуется один раз в жизни.
И потом, если вся проблема в использовании OpenID и OAuth в том, что пользователю приходится каждый раз подтверждать что-то там при заходе на каждый новый сайт, то это легко лечится минимальными изменениями в коде провайдера. Ввиду нашей специфики никакое подтверждение не нужно.
Но вот какая штука. При работе с любой из упомянутых технологий, если я всё верно понимаю, авторизация каждого пользователя хранится на каждом отдельном сервере. И возможна ситуация, когда в одном окне браузера пользователь сделал выход, а в другом он по-прежнему авторизован на одном (или на всех сразу) из сайтов. Кажется, что система для межсайтовой аутентификации должна исключать такие ситуации.
+1
Есть еще множество реализаций протокола CAS на python.
Например, django-cas-provider или CAS сервер Mozila secret-squirrel
В качестве клиента самым продвинутым был django-cas
Например, django-cas-provider или CAS сервер Mozila secret-squirrel
В качестве клиента самым продвинутым был django-cas
0
ООО Пирж это ты!
0
CAS я так понимаю работает по томуже механизму, что и OAuth, только не умеет запрашивать права на дополнительне функции.
и где тогда плюшки?
и где тогда плюшки?
+2
Если я верно понял, то каждый из наших ресурсов должен будет иметь свою подсистему для работы с сессиями аутентификации.
В принципе можно на её место поставить библиотеку, которая будет обращаться к некоторому сервису хранения сессий, а CAS делегировать право на установку cookie с id сессии.
Но, все равно будет требоваться редирект для запроса аутентификации, а когда веб-ресурс содержит контент, который может быть доступен без идентификации, не ясно когда этот редирект должен быть выполнен.
В принципе можно на её место поставить библиотеку, которая будет обращаться к некоторому сервису хранения сессий, а CAS делегировать право на установку cookie с id сессии.
Но, все равно будет требоваться редирект для запроса аутентификации, а когда веб-ресурс содержит контент, который может быть доступен без идентификации, не ясно когда этот редирект должен быть выполнен.
0
сделал собственный сервер sso
всего 20 строчек кода
особенность в том, что на множестве сайтов есть единое хранилище сессий.
про алгоритм работы можно найти в моем блоге
всего 20 строчек кода
особенность в том, что на множестве сайтов есть единое хранилище сессий.
про алгоритм работы можно найти в моем блоге
0
Sign up to leave a comment.
Одновременная межсайтовая аутентификация без велосипеда