SSO з CAS або OAuth?

Цікаво, чи варто використовувати протокол CAS або OAuth + якийсь постачальник аутентифікації для єдиного входу.

Приклад сценарію:

1. Користувач намагається отримати доступ до захищеного ресурсу, але не має автентифікації.
2. Додаток перенаправляє користувача на сервер SSO.
3. Якщо аутентифікація має місце, користувач отримує маркер від сервера SSO.
4. SSO переспрямовує на оригінальну програму.
5. Оригінальна програма перевіряє маркер на сервері SSO.
6. Якщо ж маркер у порядку, доступ буде дозволений, і програма знає ідентифікатор користувача.
7. Користувач здійснює вихід із системи та виходить із усіх підключених програм одночасно (одноразовий вихід).

Наскільки я розумію, саме це було винайдено CAS. Клієнти CAS повинні реалізувати протокол CAS, щоб використовувати послугу аутентифікації. Тепер мені цікаво використовувати CAS або OAuth на сайті клієнта (споживача). Чи замість OAuth тієї частини CAS? Чи слід віддати перевагу OAuth як новому стандарту де-факто? Чи є проста у використанні (не Sun OpenSSO!) Заміна для частини автентифікації CAS, що підтримує різні методи, такі як ім'я користувача / пароль, OpenID, сертифікати TLS ...?

Контекст:

• Різні програми повинні покладатися на автентифікацію сервера SSO і використовувати щось подібне до сеансу.
• Додатками можуть бути веб-програми GUI або (REST) ​​серійні програми.
• Сервер SSO повинен надати ідентифікатор користувача, який необхідний для отримання додаткової інформації про користувача, наприклад ролі, електронну пошту тощо, з центрального магазину інформації про користувачів.
• Потрібно мати можливість одноразового виходу.
• Більшість клієнтів написані на Java або PHP.

Я щойно відкрив WRAP , який може стати наступником OAuth. Це новий протокол, визначений Microsoft, Google та Yahoo.

Додаток

Я дізнався, що OAuth не розроблений для аутентифікації, навіть він може використовуватися для реалізації SSO, але лише разом із службою SSO, як OpenID.

OpenID, мені здається, є "новим CAS". CAS має деякі функції пропусків OpenID (наприклад, одноразовий вихід), однак додавати відсутні частини в конкретний сценарій не слід. Я думаю, що OpenID має широке визнання, і краще інтегрувати OpenID в додатки або сервери додатків. Я знаю, що CAS також підтримує OpenID, але я вважаю, що CAS не потрібен OpenID.

OpenID не є «спадкоємцем» або «замінником» CAS, вони різні, за наміром та реалізацією.

CAS централізує аутентифікацію. Використовуйте його, якщо ви хочете, щоб усі ваші (можливо, внутрішні) програми просили користувачів увійти на єдиний сервер (усі програми налаштовані так, щоб вказувати на один сервер CAS).

OpenID децентралізує аутентифікацію. Використовуйте його, якщо ви хочете, щоб ваша програма прийняла вхід користувачів у будь-яку службу аутентифікації, яку вони хочуть (користувач надає адресу сервера OpenID - адже "ім'я користувача" - це URL-адреса сервера).

Жоден із перерахованих вище авторизації не обробляє (без розширень та / або налаштування).

OAuth обробляє авторизацію, але це не замінює традиційну таблицю "USER_ROLES" (доступ користувача). Він обробляє авторизацію для третіх сторін.

Наприклад, ви хочете, щоб ваша програма інтегрувалася з Twitter: користувач міг дозволити її автоматично твітувати під час оновлення своїх даних або публікації нового вмісту. Ви хочете отримати доступ до якоїсь сторонньої послуги чи ресурсу від імені користувача, не отримуючи його пароль (що, очевидно, для користувача). Додаток запитує у Твіттера доступ, користувач його авторизує (через Twitter), і тоді програма може мати доступ.

Отже, OAuth не стосується єдиного входу (ні заміни протоколу CAS). Справа не в тому, щоб ви контролювали, що користувач може отримати доступ. Йдеться про те, щоб дозволити користувачеві контролювати спосіб доступу до своїх ресурсів сторонніми особами. Два дуже різні випадки використання.

Для описаного вами контексту CAS є, мабуть, правильним вибором.

[оновлено]

З огляду на це, ви можете реалізувати SSO з OAuth, якщо розглядати особистість користувача як захищений ресурс. Це те, що в основному роблять "Підписка на GitHub" і подібні. Можливо, це не оригінальний намір протоколу, але це можна зробити. Якщо ви керуєте сервером OAuth і обмежуєте програми лише автентифікувати його, це SSO.

Однак немає стандартного способу примусового виходу (CAS має цю функцію).

Я схильний думати про це так:

Використовуйте CAS, якщо ви керуєте / володієте системою аутентифікації користувача та вам потрібно підтримувати неоднорідний набір серверів і додатків, які потребують централізованої автентифікації.

Використовуйте OAuth, якщо ви хочете підтримувати автентифікацію користувачів із систем, у яких ви не є власником / підтримкою (наприклад, Google, Facebook тощо).

OpenID - протокол аутентифікації, OAuth та OAuth WRAP - протоколи авторизації. Вони можуть поєднуватися з гібридним розширенням OpenID .

Я б наголосив на тому, щоб люди базувались на стандартах, які набирають велику силу (більш доступна підтримка, легше залучати сторонніх осіб), навіть якщо вони не точно підходять для цієї програми. У цьому випадку OAuth має імпульс, а не CAS. Ви повинні мати можливість робити все або принаймні майже все, що вам потрібно зробити з OAuth. У якийсь пізній момент у майбутньому OAuth WRAP повинен спростити речі далі (він робить деякі корисні компроміси, використовуючи маркер носія і підштовхуючи шифрування вниз до рівня протоколу), але це ще в зародковому стані, а тим часом OAuth напевно, зробить роботу просто чудово.

Зрештою, якщо ви вирішите використовувати OpenID та OAuth, є більше бібліотек для більшої кількості мов, доступних вам і всім, кому потрібно інтегруватися в систему. У вас також є набагато більше очних яблук, які дивляться на протоколи, переконуючись, що вони справді настільки ж безпечні, як і належить.

Для мене реальна різниця між SSO та OAuth - це надання, а не автентифікація, оскільки сервер, який реалізує OAuth, очевидно, має автентифікацію (ви повинні увійти до свого google, openId або facebook, щоб OAuth стався з клієнтською програмою)

У системі SSO користувач енергії / sysadmin надає кінцевому користувачеві доступ до програми заздалегідь у додатку "SSO". В OAuth кінцевий користувач надає додатку доступ до своїх "даних" у додатку "OAuth"

Я не бачу, чому протокол OAuth не можна використовувати як частину сервера SSO. Просто вийміть екран потоку з потоку та дозвольте серверу OAuth шукати грант із резервної копії.

Стара публікація, але це може бути корисно:

CAS 3.5 підтримуватиме oAuth як клієнт та сервер. Дивіться: https://wiki.jasig.org/display/CASUM/OAuth