Сообщение Re[2]: SSO через OAuth2 от 13.04.2015 9:12
Изменено 15.04.2015 7:26 kaa.python
Здравствуйте, MayB, Вы писали:
MB>Здравствуйте, brunoid, Вы писали:
B>>Пытаюсь структурировать теорию по реализации SSO на базе OAuth2 и понимаю что не понимаю этот процесс до конца.
B>>У нас есть несколько независимых веб приложений, одно из них (например A)выступает как OAuth2 Authorization и Resource server.
B>>Второе веб приложение(например B) должно всю аутентификацию/авторизацию своих пользователей проводить через первое приложение которое выступает как SSO провайдер.
B>>Взаимодействие клиентов с приложением B происходит только через REST endpoints которые оно предоставляет.
B>>Задача — засекьюрить REST endpoints приложения B через OAuth2 приложения A.
B>>Как должен выглядеть этот процесс, что после успешного процесса авторизации я должен сохранять на стороне приложения B для того что б все последующие запросы от пользователя к приложениею B не валидировать с приложением A?
B>>Или же я в любом случае должен валидировать access token который будет приходить от пользователя приложению B с приложением A ?
B>>Расскажите пожалуйста как правильно организовать этот процесс в вышеуказанной архитектуре системы. Спасибо
MB>И так, все не так сложно как пишется в манулах
MB>OAuth — это только авторизация, поэтому если Вы используете OAuth SSO, только как SSO не надо использовать OAuth. Если сервер B это Ваш сервер и вы его "пилите", зачем такой overhead вообще?
MB>Но если Вы решили что нужен:
MB>Есть несколько подходов именуются как grand_type:
MB>- если пишете своего клиента, тогда дешевле пользоваться 'grant_type:password' — в один вызов получаете токен
MB>- для сторонних клиентов со своим сервером лучше использовать 'grant_type:authorization_code'
MB>- для простых сторонних клиентов (мобилка, десктоп, джаваскрипт) лучше всего 'grant_type:implicit'
MB>По OAuth 2 простыми словами тут
MB>По спеке не указано стоит ли делать Authorization server & Resource server вместе, но т.к. у Вас планируется SSO, лучше если Authentication Server будет сам по себе, т.е. в Вашем случае это должно быть три сервера, т.к. в случае нового релиза Resource Server-а вся система будет недоступна т.к. Authorization server рестартует, хотя и не менялся. И вообще когда дело дошло до SSO, то обычно такие вещи не разарабатывают, их настраивают, для этого оно и придуманно.
MB>Теперь еще про токен и запросы на Autherization Server. Для начала попробуйте простой вариант, токен всегда посылается Auth серваку, если будут проблемы связанные с сетью (скоростью по сети), можно подумать о том чтобы рассшарить алгоритм сверки и валидировать локально. (Пока такого не делал, но слушал презентацию от CloudFoundry они такое рекомендовали).
MB>П.С.
MB>Мне кажется, что Вы не до конца понимаете зачем нужен OAuth. Еще раз, если речь идет о независимых серверах, которые Вы сами пишете, лучше подумать о простом SSO. Просто в спеке по OAuth нет понятия пользователя — это ресурс. А пользователь в спеке OAuth (client) — это третья сторона, которая хочет воспользоваться чужим ресурсом. Если вы пишете свои сервера чужих не должно быть.
спасибо за ваш ответ !
Возможно вы правы и мне нужно просто SSO. Вот что я имею на данный момент. Есть RESTful endpoints на Spring MVC. Некоторые из них нужно засекьюрить для пользователей с опредленными ролями. В данный момент хочу прикрутить что то вроде готового SSO который позволит аутентифицировать пользоветелй как путем создания аккаунтов методом заполнения регистрационной формы так и через OAuth провайдеров, таких как Facebook, Google, Yahoo, Twitter и так далее. Авторизация в приложении уже реализована на базе Spring Security. Посоветуйте пожалуйста Java SSO фреймворк который возьмет на себя аутентификацию описанную выше и хорошо проинтегрируется со Spring Security.
MB>Здравствуйте, brunoid, Вы писали:
B>>Пытаюсь структурировать теорию по реализации SSO на базе OAuth2 и понимаю что не понимаю этот процесс до конца.
B>>У нас есть несколько независимых веб приложений, одно из них (например A)выступает как OAuth2 Authorization и Resource server.
B>>Второе веб приложение(например B) должно всю аутентификацию/авторизацию своих пользователей проводить через первое приложение которое выступает как SSO провайдер.
B>>Взаимодействие клиентов с приложением B происходит только через REST endpoints которые оно предоставляет.
B>>Задача — засекьюрить REST endpoints приложения B через OAuth2 приложения A.
B>>Как должен выглядеть этот процесс, что после успешного процесса авторизации я должен сохранять на стороне приложения B для того что б все последующие запросы от пользователя к приложениею B не валидировать с приложением A?
B>>Или же я в любом случае должен валидировать access token который будет приходить от пользователя приложению B с приложением A ?
B>>Расскажите пожалуйста как правильно организовать этот процесс в вышеуказанной архитектуре системы. Спасибо
MB>И так, все не так сложно как пишется в манулах
MB>OAuth — это только авторизация, поэтому если Вы используете OAuth SSO, только как SSO не надо использовать OAuth. Если сервер B это Ваш сервер и вы его "пилите", зачем такой overhead вообще?
MB>Но если Вы решили что нужен:
MB>Есть несколько подходов именуются как grand_type:
MB>- если пишете своего клиента, тогда дешевле пользоваться 'grant_type:password' — в один вызов получаете токен
MB>- для сторонних клиентов со своим сервером лучше использовать 'grant_type:authorization_code'
MB>- для простых сторонних клиентов (мобилка, десктоп, джаваскрипт) лучше всего 'grant_type:implicit'
MB>По OAuth 2 простыми словами тут
MB>По спеке не указано стоит ли делать Authorization server & Resource server вместе, но т.к. у Вас планируется SSO, лучше если Authentication Server будет сам по себе, т.е. в Вашем случае это должно быть три сервера, т.к. в случае нового релиза Resource Server-а вся система будет недоступна т.к. Authorization server рестартует, хотя и не менялся. И вообще когда дело дошло до SSO, то обычно такие вещи не разарабатывают, их настраивают, для этого оно и придуманно.
MB>Теперь еще про токен и запросы на Autherization Server. Для начала попробуйте простой вариант, токен всегда посылается Auth серваку, если будут проблемы связанные с сетью (скоростью по сети), можно подумать о том чтобы рассшарить алгоритм сверки и валидировать локально. (Пока такого не делал, но слушал презентацию от CloudFoundry они такое рекомендовали).
MB>П.С.
MB>Мне кажется, что Вы не до конца понимаете зачем нужен OAuth. Еще раз, если речь идет о независимых серверах, которые Вы сами пишете, лучше подумать о простом SSO. Просто в спеке по OAuth нет понятия пользователя — это ресурс. А пользователь в спеке OAuth (client) — это третья сторона, которая хочет воспользоваться чужим ресурсом. Если вы пишете свои сервера чужих не должно быть.
спасибо за ваш ответ !
Возможно вы правы и мне нужно просто SSO. Вот что я имею на данный момент. Есть RESTful endpoints на Spring MVC. Некоторые из них нужно засекьюрить для пользователей с опредленными ролями. В данный момент хочу прикрутить что то вроде готового SSO который позволит аутентифицировать пользоветелй как путем создания аккаунтов методом заполнения регистрационной формы так и через OAuth провайдеров, таких как Facebook, Google, Yahoo, Twitter и так далее. Авторизация в приложении уже реализована на базе Spring Security. Посоветуйте пожалуйста Java SSO фреймворк который возьмет на себя аутентификацию описанную выше и хорошо проинтегрируется со Spring Security.
Re[2]: SSO через OAuth2
Здравствуйте, MayB, Вы писали:
MB>Мне кажется, что Вы не до конца понимаете зачем нужен OAuth. Еще раз, если речь идет о независимых серверах, которые Вы сами пишете, лучше подумать о простом SSO. Просто в спеке по OAuth нет понятия пользователя — это ресурс. А пользователь в спеке OAuth (client) — это третья сторона, которая хочет воспользоваться чужим ресурсом. Если вы пишете свои сервера чужих не должно быть.
спасибо за ваш ответ !
Возможно вы правы и мне нужно просто SSO. Вот что я имею на данный момент. Есть RESTful endpoints на Spring MVC. Некоторые из них нужно засекьюрить для пользователей с опредленными ролями. В данный момент хочу прикрутить что то вроде готового SSO который позволит аутентифицировать пользоветелй как путем создания аккаунтов методом заполнения регистрационной формы так и через OAuth провайдеров, таких как Facebook, Google, Yahoo, Twitter и так далее. Авторизация в приложении уже реализована на базе Spring Security. Посоветуйте пожалуйста Java SSO фреймворк который возьмет на себя аутентификацию описанную выше и хорошо проинтегрируется со Spring Security.
MB>Мне кажется, что Вы не до конца понимаете зачем нужен OAuth. Еще раз, если речь идет о независимых серверах, которые Вы сами пишете, лучше подумать о простом SSO. Просто в спеке по OAuth нет понятия пользователя — это ресурс. А пользователь в спеке OAuth (client) — это третья сторона, которая хочет воспользоваться чужим ресурсом. Если вы пишете свои сервера чужих не должно быть.
спасибо за ваш ответ !
Возможно вы правы и мне нужно просто SSO. Вот что я имею на данный момент. Есть RESTful endpoints на Spring MVC. Некоторые из них нужно засекьюрить для пользователей с опредленными ролями. В данный момент хочу прикрутить что то вроде готового SSO который позволит аутентифицировать пользоветелй как путем создания аккаунтов методом заполнения регистрационной формы так и через OAuth провайдеров, таких как Facebook, Google, Yahoo, Twitter и так далее. Авторизация в приложении уже реализована на базе Spring Security. Посоветуйте пожалуйста Java SSO фреймворк который возьмет на себя аутентификацию описанную выше и хорошо проинтегрируется со Spring Security.