Інтеграція SSO / аутентифікації із зовнішньою службою каталогів

Я збираюся розпочати роботу над прототипом для клієнта - і однією з необхідних функцій є інтеграція з власною системою аутентифікації / реєстрації користувачів.

Ця система буде виконувати роль авторитетної бази даних користувачів та забезпечує RESTful інтерфейс для створення нових користувачів та автентифікації дійсних користувачів.

1. Мені потрібно мати можливість створювати нових користувачів у WP, і як частина цього процесу здійснювати виклик до зовнішнього API аутентифікації, щоб або створити / перевірити цього користувача.

2. Особа, яка є дійсним користувачем, але не відома WP, повинна мати можливість увійти в систему, щоб коментувати, не потребуючи самостійної реєстрації на сайті WP.

3. Людина, яка увійшла на загальний веб-сайт, також повинна автоматично входити в WordPress.

Я думаю, що це наступний шлях.

• Для (1) - чи можу я використати реєстраційний гачок?

• Для (2) - я припускаю, що я підключаю фільтр автентифікації - тобто коли хтось намагається увійти, я вловлюю це, я здійснюю виклик до зовнішньої системи, а потім обробляю логін WP або перенаправляю їх до процесу реєстрації, де ( 1) бере ур.

• Для (3) - прочитати печиво для входу, встановлене головним сайтом, і продовжити з (2)?

Я думаю, мені також потрібно вставити запис у таблицю користувачів та usermeta.

Отже, чи має вищезазначене сенс - чи я не думав про щось. У когось є якісь хороші ресурси для допомоги у цьому (@hakre - я бачив, що ви пропрацювали над цим !!).

Оновлення

Тому я все-таки трохи забиваю голову проти цього, по суті я намагаюся підключити фільтр автентифікації і використовую це для:

1. перевірте, чи встановлено файл cookie для входу на веб-сайт "головний", і якщо він є, скасуйте його проти API автентифікації, і якщо він дійсний, примушуйте входити в систему WP wp_signon(), використовуючи інформацію, що міститься в файлі cookie головного сайту (електронна пошта та хешований пароль) як облікові дані для WP
2. якщо файл cookie не встановлено, перейдіть на сторінку входу на головний сайт і отримайте або логін / реєстрацію, а потім поверніться до кроку 1
3. якщо немає користувача WP, коли існує автентифікований користувач головного сайту, створіть його, а потім так "прозоре" реєстрацію (тобто щоб користувач не бачив форму входу в WP)

В основному я хочу повністю приховати форму входу в WP для користувачів, які просто збираються в основному коментувати, а пізніше знайти спосіб дозволити авторам та адміністратору отримати доступ до неї безпосередньо.

Це відбувається досить повільно, ось, з чим я міг би скористатися допомогою:

• правильний фільтр для аутентифікації? Схоже, його не викликають у будь-яких ситуаціях, на які я б очікував - наприклад, мета-віджет відображає посилання для входу / виходу без аутентифікаційного запуску гака

• я можу отримати wp_signon()повернути WP_Userоб'єкт (що свідчить про успіх), але це не впливає на статус, який увійшов - тобто мета-віджет все ще буде відображати "Вхід" навіть після оновлення.

Будь-яка допомога вдячно отримана :)

Гаразд, підхід, який працює для мене, такий:

1. Припустимо, що основна база даних користувачів сайту є авторитетною. Основне cookie для входу на сайт містить ідентифікатор та хеш пароля сайту.

2. Отримайте файл cookie з головного веб-сайту та скасуйте його відносно API автентифікації головного сайту

3. Якщо дійсно, використовуйте адресу електронної пошти зі значенням повернення як 'user_login'значення для WP, а хешований пароль сайту - як пароль WP.

4. Перевірте, чи існує цей користувач у WP, використовуючи wp_authenticate('user_login', 'user_pass'). Це повертає WP_Userоб'єкт на успіх або WP_Errorоб'єкт на збій.

5. Якщо WP_Error/is_wp_error(), тоді скористайтеся командою use wp_update_user()для створення користувача (або оновлення користувача зі зміненим паролем).

6. Ввійти через wp_set_current_user(), wp_set_auth_cookie()іdo_action('wp_login, id)

(Це все міститься у функції, що додається до 'init'дії)

Це, здається, працює - дійсні користувачі сайту, невідомі WP, автоматично створюються. Зміни пароля обслуговуються, і якщо встановлено файл cookie сайту, а користувач WP існує, SSO є автоматичним і досить безпроблемним.

Вся система аутентифікації підключається. Я пропоную переглянути наявні плагіни, щоб зрозуміти, як перекрити систему. Можливо, переглянувши деякі плагіни LDAP ?

Деякі призначені для користувача функції , пов'язані визначаються умовно на !function_exists()в wp-includes/pluggable.phpі легко перевизначити за допомогою власних версій.

Увімкнення режиму одиночного входу в WordPress потребує 18 годин боротьби, але це може зайняти лише кілька хвилин:

В основному, ви хочете використовувати https://wordpress.org/plugins/wp-force-login/ та модифіковану версію https://as.wordpress.org/plugins/jwt-authenticator/, а потім створити аутентифікацію -захищена кінцева точка на вашому головному сайті, яка генерує JWT (JSON Web Token) і переспрямовує назад до спеціальної URL-адреси вашого сайту WordPress.

Дивіться повний код тут .