Розуміння безпеки й ідентичності Salesforce: коли використовувати єдиний вхід і OAuth. Вступ
У цьому блозі ми прагнемо внести ясність у безпеку й ідентичність Salesforce, зосередившись на тому, коли використовувати єдиний вхід (SSO) і OAuth. Ці знання критично важливі, щоб орієнтуватися в різних сценаріях доступу до Salesforce — через прямий вхід, SSO чи OAuth.
Коли використовувати стандартний вхід, єдиний вхід чи OAuth
Прямий вхід:
Сценарій: Користувач через браузер хоче зайти в Salesforce, щоб переглядати його сторінки.
Спосіб доступу: Прямий вхід у Salesforce або єдиний вхід через стороннього постачальника ідентичності, що дає безперешкодний доступ без повторної автентифікації.
OAuth із мобільними застосунками:
Сценарій: Користувач застосовує мобільний застосунок, щоб отримати доступ до даних Salesforce через API, а не через відображення нативних сторінок Salesforce.
Спосіб доступу: Тут використовується OAuth, особливо коли взаємодія відбувається через мобільні пристрої, зокрема телефони чи планшети з браузерними технологіями. Такий підхід дає змогу мобільним застосункам захищено взаємодіяти з API Salesforce.
OAuth зі сторонніми серверами:
Сценарій: Користувач через браузер спілкується зі стороннім сервером, якому потрібен доступ до даних Salesforce від імені користувача. Приклади — плагіни для email чи інші системи, інтегровані із Salesforce.
Спосіб доступу: Для захищеного доступу використовується OAuth зі спеціальним протоколом “Web Server with PKCE” (Proof Key for Code Exchange).
OAuth flows для різних сценаріїв
Client Credentials Flow: Призначений для клієнтського процесу (як-от зовнішніх серверів, що виконують пакетні завантаження чи експорти), який звертається до Salesforce з призначеним акаунтом інтеграційного користувача.
JWT, SAML Bearer Assertion і SAML Assertion Flows: Ці flows — для сценаріїв, де клієнтському процесу треба діяти від імені конкретного користувача без його безпосередньої участі. Тут процес діє від імені призначеного користувача, зберігаючи контекст безпеки файлів цього користувача.
Device Flow: Цей flow ініціює пристрій, якому для схвалення потрібне втручання людини. Наприклад, застосунок на смарт-телевізорі просить користувача ввести код для підтвердження доступу.
Asset Flow: Корисний для пристроїв інтернету речей (IoT), яким потрібно підключатися до Salesforce для читання чи запису даних.
Підсумок і висновок
По суті, спосіб доступу значною мірою залежить від сценарію:
Для прямого доступу до Salesforce через браузер використовуйте прямий вхід або єдиний вхід, якщо у вас є сервіс ідентичності.
Для непрямого доступу через мобільні пристрої, сторонні сервери чи автоматизовані процеси переважним методом є OAuth. Тут треба вирішити, чи діятиме OAuth від імені користувача-людини, чи від імені акаунта інтеграційного користувача.
У наступних статтях ми глибше розглянемо кожен сценарій і варіант використання, щоб дати всебічне розуміння.
Слідкуйте за новинами
Вирушайте в подорож Salesforce Identity впевнено! Більше думок і порад — тут, на www.SteveTechArc.com, і на YouTube-каналі @SteveTechArc (opens in a new tab). Підпишіться й поглиблюйте розуміння Salesforce Identity.
Допомагаю змінювати світ, ділячись знаннями про інтеграцію з колегами-архітекторами і тими, хто йде до архітектури!
Транскрипт оброблено за допомогою ШІ
STA 3.9