Розкриваємо безпеку Salesforce: тонкощі налаштування SAML і потоку SSO
У світі Salesforce може бути важливо розуміти механіку безпеки й ідентичності з єдиним входом (SSO). Зануримося глибоко у взаємодію Salesforce, коли він працює як постачальник послуг під зовнішнім постачальником ідентичності (IDP), і висвітлимо ключові налаштування й потоки.
Розбір налаштувань:
Ключова роль браузера: У нашій інтегрованій технологічній екосистемі браузер — не просто глядач, а активний посередник, що забезпечує захищене спілкування між IDP і Salesforce — постачальником послуг.
Діалоги SAML: Методологія спілкування SSO обертається навколо надсилання SAML-запитів до IDP. У відповідь вона очікує їхніх SAML-тверджень — по суті, цифрових «доказів» автентифікації.
Довіра через цифровий сертифікат: Щоб забезпечити захищену й довірену взаємодію, Salesforce і IDP обмінюються цифровим сертифікатом. Це електронне рукостискання — фундамент їхніх захищених відносин.
Покрокове налаштування:
[caption id="" align=“alignnone” width=“1780”]
Налаштування SAML [/caption]
На боці IDP: Налаштування охоплюють створення connected app, визначення параметрів цифрового сертифіката і введення шляхів Url Redirect до постачальника послуг.
У домені Salesforce: Кроки — від налаштування ‘My Domain’ і увімкнення SAML до ключового кроку завантаження сертифіката IDP. Крім того, необхідно налаштувати перенаправлення назад до IDP.
Ідентичність користувача через Federation ID: Salesforce однозначно ідентифікує користувачів з IDP за Federation ID. Думайте про нього як про спеціальну мітку — як-от табельний номер чи інші унікальні ідентифікатори, — що допомагає безперешкодно ідентифікувати користувачів.
Глибоке занурення в потік SSO:
[caption id="" align=“alignnone” width=“1780”]
Потік входу, ініційований SP [/caption]
1a/1b Початковий доступ користувача: На початку дня користувачі можуть спробувати звернутися до захищеного ресурсу Salesforce. Якщо вони не увійшли, Salesforce це виявляє й видає команду перенаправлення.
2a Шлях до IDP: Salesforce перенаправляє користувача до його IDP. Тут і починається справжня подорож: від традиційних екранів входу до розвиненіших методів, як-от багатофакторна автентифікація.
2b Печатка схвалення IDP: Щойно ідентичність користувача перевірено, IDP створює й надсилає в Salesforce SAML-твердження, що ручається за користувача.
3a/3b/4 Гостинні двері Salesforce: Отримавши схвалення IDP, Salesforce проводить власну перевірку, після чого запускає сесію. Для користувачів усе відбувається безшовно: вони клацають посилання Salesforce, проходять автентифікацію — і готово, вони на своїй сторінці Salesforce.
Підсумок
Безшовний досвід — ключовий аспект цього танцю потоку, ініційованого постачальником послуг. Користувачі, що йдуть напряму в Salesforce, роблять короткий обхід: їх проводять до автентифікації, а після перевірки плавно повертають у Salesforce.
Ця гармонійна взаємодія між Salesforce, IDP і браузерами користувачів може здаватися складною, але вона задумана, щоб збалансувати заходи безпеки й швидкий доступ користувачів.
Слідкуйте за новинами: у майбутніх постах ми глибше розглянемо спеціалізовані аспекти, як-от цікавий світ глибоких посилань і relay states. Для тих, кого цікавлять практичні демонстрації, я готую детальні відео, що показують налаштування в середовищах Salesforce org.
Щоб отримувати такі цікаві матеріали й більше, підпишіться на YouTube-канал @SteveTecharc. Разом пройдімо лабіринт безпеки Salesforce!
Слідкуйте за новинами
Вирушайте в подорож Salesforce Identity впевнено! Більше думок і порад — тут, на www.SteveTechArc.com, і на YouTube-каналі @SteveTechArc (opens in a new tab). Підпишіться й поглиблюйте розуміння Salesforce Identity.
Допомагаю змінювати світ, ділячись знаннями про інтеграцію з колегами-архітекторами і тими, хто йде до архітектури!
Транскрипт оброблено за допомогою ШІ
Лишайтеся допитливими, лишайтеся захищеними!
STA 3.4