SSO: що таке єдиний вхід? Універсальний сервіс єдиного входу для підприємств

Single Sign-on Service

 

 

Вміст

Що означає SSO та як він працює

Недоліки та переваги єдиного входу

Приклади єдиного входу

Універсальна служба SSO від Hideez

Приклад налаштування ASA AnyConnect VPN для Hideez Enterprise Server через SAML

Налаштувати HES як ідентифікатор

Налаштувати ASA для SAML через CLI

Додати постачальника послуг до HES

Остаточна перевірка

Поширені проблеми

Усунення несправностей

 

Переглядаючи програму чи веб-сайт, ви, ймовірно, бачили опцію входу за допомогою Facebook або Google. І наступне, що ви знаєте, ви чарівним чином увійшли на сторонній веб-сайт, навіть не створивши обліковий запис.

Це не магія, це технологія єдиного входу або SSO. Що це таке, як він працює і чому так багато сучасних організацій використовують його з міркувань безпеки?

Що означає SSO та як це працює

Єдиний вхід – це процес автентифікації користувача, який дозволяє користувачам отримати доступ до кількох програм за допомогою одного набору облікових даних, як-от ім’я користувача та пароль. Це означає, що після того, як користувач увійшов у систему, йому не потрібно повторно входити в систему для кожної програми, пов’язаної з цією системою.

Насправді єдиний вхід – це об’єднана домовленість про управління ідентифікаційною інформацією між трьома об’єктами: 

  • Користувачі  Окремі люди повинні мати доступ до різних служб. Вони повинні мати можливість керувати особистою інформацією, як-от логін або пароль, і їх можна однозначно ідентифікувати.
  • Постачальники послуг (SP) Традиційно, це веб-сайти та програми, до яких користувачі хочуть отримати доступ, але вони можуть включати різноманітні продукти та послуги, такі як доступ до Wi-Fi, ваш телефон або пристрої «Інтернет речей».
  • Постачальники ідентифікаційних даних (IdP) Бази даних, які зберігають ідентифікаційні дані користувачів, які потім можуть бути об’єднані з різними ІТ-ресурсами. Вони також можуть зберігати багато екземплярів ідентифікації користувача, які містять таку інформацію, як імена користувачів, паролі, ключі SSH, біометрична інформація та інші атрибути. Одним із найпопулярніших постачальників ідентифікаційних даних сьогодні є Microsoft Active Directory, який був розроблений для керування іменами користувачів і паролями Windows і підключення їх до локальних ІТ-ресурсів Windows.

Для того, щоб SSO працював, більшість додатків покладаються на відкриті стандартні протоколи, щоб визначити, як постачальники послуг та постачальники ідентифікаційних даних можуть обмінюватися один з одним ідентифікаційною інформацією та інформацією про автентифікацію. Найпоширенішими протоколами є SAML , OAuth і OpenID Connect (OIDC), які безпечно дозволяють одному сервісу отримувати доступ до даних іншого.

Сьогодні ми бачимо тенденцію, яку компанії починають усвідомлювати: віддалена робота з дому означає, що більше користувачів повинні входити в свої облікові записи через Інтернет, щоб отримати доступ до важливої ​​інформації. І це вся нова сфера потенційних векторів атаки. Злочинці це вже знають і цим користуються. Тому все більше компаній починають боротися з новими загрозами, впроваджуючи рішення SSO.

Недоліки та переваги єдиного входу

Основною перевагою системи єдиного входу є чудовий користувальницький досвід та зручність, яку він надає користувачам. Вони мають мінімум паролів для запам’ятовування, це спрощує процес входу та зменшує ймовірність фішингу.

SSO особливо чудово підходить для компаній, які працюють віддалено через COVID-19, оскільки служби єдиного входу забезпечують найбільш безпечну та зручну автентифікацію для віддаленого входу. Використання SSO також може бути частиною інтегрованої системи керування доступом для швидше надання та деініціалізації користувачів.

З іншого боку, SSO створює ризики, оскільки створює єдину точку збою, яку зловмисники можуть використати для отримання доступу до інших програм. Крім того, як і для багатьох ІТ-інструментів, SSO вимагає впровадження та налаштування, які можуть бути досить дорогими.

Багато постачальників системи єдиного входу стягують окремо за функцією, тому комісія швидко збільшується і може стати важким тягарем для бюджету малого та середнього бізнесу.

У всякому разі, ми вважаємо, що зручність SSO коштує всіх недоліків, які він приносить.

Приклади єдиного входу

Типовим і хорошим прикладом єдиного входу є Google. Будь-який користувач, який увійшов в одну зі служб Google, автоматично входить в інші служби, такі як Gmail, Google Drive, Youtube, Google Analytics тощо.

Єдиний вхід зазвичай використовує центральну службу, яка організовує єдиний вхід між кількома клієнтами, якими у випадку Google є облікові записи Google.

Переходячи до безпеки підприємства, сьогодні існує багато продуктів і послуг єдиного входу для бізнесу. Зазвичай це менеджери паролів із клієнтськими та серверними компонентами, які реєструють користувача в цільові програми, відтворюючи облікові дані користувача.

Служба аутентифікації Hideez є одним із таких прикладів безпечних рішень SSO. Однією з унікальних переваг Hideez SSO є те, що він дозволяє комбінувати базові методи автентифікації (ім’я користувача/пароль + одноразовий пароль) з повністю безпарольними вхідними засобами (токени FIDO2 або мобільний додаток).

Отже, як працює система єдиного входу Hideez?

Крок 1. Користувач отримує доступ до будь-якого постачальника послуг, тобто до програми , що підтримує протоколи SAML або OpenID;

Крок 2. Постачальник послуг надсилає запит SAML/OIDC на Hideez Server, і користувач автоматично перенаправлено на сервер Hideez;

Single Sign-on Service

Крок 3. Користувачеві пропонується ввести дані для входу або вибрати один із доступних методів аутентифікації: апаратний ключ безпеки (Yubikey, багатофункціональний Hideez Key або будь-який інший маркер фізичної безпеки), або Hideez Authenticator мобільний додаток;

Крок 4. Сервер Hideez надсилає результат автентифікації постачальнику послуг і перенаправляє користувача назад до початкової програми.

Крок 5. Користувач автентифікується, імовірно, нічого не помічаючи, окрім кількох викликів переспрямування в рядку URL-адрес його браузера.

Single Sign-on Service

Універсальна служба SSO від Hideez

Служба єдиного входу Hideez – це постачальник ідентифікаційних даних SAML (IdP), який додає SSO до Windows Active Directory за допомогою федерації SAML 2.0. Адміністратори можуть налаштувати єдиний вхід до будь-якої веб-або мобільної програми, яка підтримує стандарти OpenID Connect або SAML. На додаток до цього, ми робимо єдиний вхід повністю без пароля!

На відміну від системи єдиного входу з традиційними логінами на основі пароля, Hideez SSO може усунути паролі та замінити їх на FIDO2/Mobile App досвід без пароля, де це можливо. Навіть якщо деякі з ваших програм не підтримують стандарти SAML або OIDC і їх неможливо зробити повністю безпарольними, ви можете використовувати Hideez Key як апаратний менеджер паролів і автоматично заповнювати облікові дані для входу натисканням кнопки.

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

  • Смартфони Hideez Authenticator – це програма єдиного входу для пристроїв Android та iOS. Він може перетворити смартфони користувачів у безпарольні апаратні токени, які замінюють їхні імена користувачів та паролі на безпечний вхід на основі одноразових QR-кодів використання біометричної перевірки або підтвердження PIN-коду на смартфоні кінцевого користувача
  • Апаратні ключі безпеки. Токени Hideez Key — це багатофункціональні пристрої Bluetooth/NFC/USB, захищені PIN-кодом. Ви можете використовувати їх для входу в служби без паролів на основі стандарту FIDO2, зберігати облікові дані для входу на основі пароля, генерувати одноразові паролі для 2FA і навіть блокувати або розблоковувати Windows комп’ютери на основі близькості пристрою.

Hideez Enterprise Server інтегрується з Microsoft Active Directory, Azure Active Directory та системами ідентифікації LDAP, щоб спростити підключення та керування користувачами . Ваші співробітники можуть використовувати лише одну програму SSO для доступу до всіх речей, що робить службу Hideez SSO надзвичайно зручною для користувачів. Не кажучи вже про те, що вам не потрібно пам’ятати облікові дані для входу або думати про запобігання фішингу та крадіжки особистих даних.

Hideez перевершує всіх сучасних конкурентів за зручністю та ціною, пропонуючи повну відповідність найсильнішим стандартам аутентифікації, таким як GDPR, NIST, PSD2, PSI-DSS та HIPAA. Завчасно вживаючи запобіжних заходів, ви можете заощадити багато грошей і часу в довгостроковій перспективі.

Заплануйте демонстрацію або подайте запит на безкоштовну 30-денну пробну версію Hideez Єдиний вхід і зафіксуйте майбутнє безпеки без пароля!

 

Приклад налаштування ASA AnyConnect VPN для Hideez Enterprise Server через SAML

Hideez Enterprise Server (HES) підтримує стандарт SAML 2.0 (Security Assertion Markup Language) для автентифікації користувачів. HES — це IdP (постачальник ідентифікаційних даних), який дозволяє SSO для всіх веб-додатків (SP, Service Provider), які підтримують SAML.

Оскільки HES підтримує авторизацію без пароля FIDO2, постачальники послуг автоматично отримують можливість авторизуватися за допомогою апаратних ключів безпеки без створення та введення паролів.

Вимоги

Cisco рекомендує знати такі теми:

  • Основні знання конфігурації RA VPN на ASA
  • Основні знання SAML та Microsoft Active Directory.
  • Ліцензії AnyConnect увімкнено (APEX або лише VPN).

Використані компоненти

Інформація в цьому документі заснована на таких версіях програмного та апаратного забезпечення:

  • Hideez Enterprise Server 3.9+
  • Microsoft Active Directory
  • Cisco ASA 9.7+ і Anyconnect 4.6+
  • Робочий профіль AnyConnect VPN

Інформація в цьому документі була створена з пристроїв у певному лабораторному середовищі. Усі пристрої, які використовуються в цьому документі, почали з очищеної (за замовчуванням) конфігурації. Якщо ваша мережа працює, переконайтеся, що ви розумієте потенційний вплив будь-якої команди. Ви також можете зіставити користувачів із певними ролями програми на основі правил, які ви визначаєте у своїх налаштуваннях у Active Directory, Cisco ASA та Anyconnect.

Довідкова інформація

SAML – це основа на основі XML для обміну даними аутентифікації та авторизації між доменами безпеки.Це створює коло довіри між користувачем, постачальником послуг (SP) та постачальником ідентифікаційних даних (IdP), що дозволяє користувачеві ввійти в систему за один раз для кількох послуг, які Hideez Enterprise Server плавно інтегрується з пристроєм Cisco ASA VPN, щоб забезпечити додаткові безпеки для входу Cisco AnyConnect VPN.

Компоненти SAML

Метадані: це документ на основі XML, який забезпечує безпечну транзакцію між IdP та SP. Це дозволяє IdP та SP вести переговори про угоди.

Ролі, які підтримуються пристроями (IdP, SP)

Пристрій може підтримувати більше однієї ролі і може містити значення як для SP, так і для IdP. Під полем EntityDescriptor міститься IDPSSODescriptor, якщо інформація, що міститься для IdP з єдиним входом, або SPSSODescriptor, якщо міститься інформація для SP з єдиним входом. Це важливо, оскільки для успішного налаштування SAML потрібно взяти правильні значення з відповідних розділів.

Ідентифікатор об’єкта: Це поле є унікальним ідентифікатором SP або IdP. Один пристрій може мати кілька служб і може використовувати різні ідентифікатори об’єктів, щоб розрізняти їх. Наприклад, ASA має різні ідентифікатори Entity для різних тунельних груп, які потребують аутентифікації. IdP, що аутентифікує кожну тунельну групу, має окремі записи Entity ID для кожної тунельної групи, щоб точно ідентифікувати ці послуги.

ASA може підтримувати декілька IdP і має окремий ідентифікатор сутності для кожного IdP, щоб розрізняти їх. Якщо будь-яка сторона отримує повідомлення від пристрою, який не містить ідентифікатор об’єкта, який був налаштований раніше, пристрій, імовірно, видаляє це повідомлення, а автентифікація SAML не вдається. Ідентифікатор Entity можна знайти в полі EntityDescriptor поруч із entityID.

URL-адреси служби: Вони визначають URL-адресу послуги SAML, що надається SP або IdP. Для IdP це найчастіше послуги єдиного виходу та єдиного входу. Для постачальників послуг це зазвичай Служба підтримки споживачів та Служба єдиного виходу.

URL-адреса служби єдиного входу, знайдена в метаданих IdP, використовується SP для перенаправлення користувача до IdP для аутентифікації. Якщо це значення налаштовано неправильно, IdP не отримує або не може успішно обробити запит аутентифікації, надісланий SP.

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

URL-адресу служби єдиного виходу можна знайти як на SP, так і на IdP. Він використовується для полегшення виходу з усіх служб SSO з SP і є необов'язковим для ASA. Коли URL-адреса служби SLO з метаданих IdP налаштована на SP, коли користувач виходить із служби на SP, SP надсилає запит IdP. Після того, як IdP успішно виведе користувача зі служб, він перенаправляє користувача назад до SP, використовуючи URL-адресу служби SLO, знайдену в метаданих SP.

Прив'язування SAML для URL-адрес служби: прив'язки – це метод, який SP використовує для передачі інформації до IdP і навпаки для послуг. Це включає переспрямування HTTP, HTTP POST і артефакт. Кожен метод має різний спосіб передачі даних. Метод зв’язування, який підтримує служба, входить у визначення цієї служби. Наприклад: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://saml.example.com/simplesaml/saml2/idp/SSOService.php"/ > . ASA не підтримує прив’язування артефакту. ASA завжди використовує метод HTTP Redirect для запитів автентифікації SAML, тому важливо вибрати URL-адресу служби SSO, яка використовує прив’язку HTTP Redirect, щоб IdP очікував цього.

Сертифікати для операцій підпису та шифрування

Щоб забезпечити конфіденційність та цілісність повідомлень, надісланих між SP та IdP, SAML включає можливість шифрувати та підписувати дані Сертифікат, який використовується для шифрування та/або підпису даних, може бути включено в метадані, щоб що одержувач може перевірити повідомлення SAML і переконатися, що воно надходить із очікуваного джерела. Сертифікати, які використовуються для підписання та шифрування, можна знайти в метаданих у розділах KeyDescriptor use="signing" і KeyDescriptor use="encryption" відповідно, потім X509Certificate. ASA не підтримує шифрування повідомлень SAML.

 

Налаштувати HES як ідентифікатор

Крок 1. Встановіть налаштування постачальника ідентифікаційних даних

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

Сертифікат у форматі «.pfx» необхідний для роботи протоколу SAML. Його можна створити, наприклад, за допомогою програми OpenSSL або за допомогою наявного сертифіката. Файл сертифіката необхідно скопіювати на сервер HES (наприклад, папку з бінарними файлами та налаштуваннями).

Увійдіть на сервер HES, потім перейдіть до Налаштування -> Параметри -> SAML. Потім натисніть кнопку [Set IdP Settings]:

Виберіть свій файл .pfx та введіть пароль для файлу .pfx. Також потрібно вибрати відповідний алгоритм:

SignatureAlgorithm - алгоритм підпису. Він повинен відповідати алгоритму, за яким було створено сертифікат pfx. Можливі варіанти: SHA1, SHA256, SHA384, SHA512.

Крок 2. Отримайте файл метаданих HES

На тій же сторінці (Налаштування -> Параметри -> SAML) після встановлення сертифіката .pfx можна:

  • Переглянути метадані · Завантажити метадані · Завантажити сертифікат відкритого ключа

Метадані – це файл XML, який містить всю необхідну інформацію про налаштування IdP та сертифікат відкритого ключа. ASA дозволяє вам імпортувати метадані IdP під час налаштування SAML, що спрощує налаштування. Ви також можете завантажити окремий сертифікат, якщо необхідно, або переглянути всі метадані на екрані.

Для наступних кроків потрібно завантажити файл метаданих та файли сертифікатів.

 

Налаштувати ASA для SAML через CLI

Крок 1. Створіть Trustpoint та імпортуйте наш сертифікат SAML

# конфігурація t

# точка довіри crypto ca HES-SAML

відкликання-перевірка немає

без використання ідентифікатора

термінал реєстрації

без ca-check

# crypto ca автентифікує HES-SAML

-----ПОЧАТОК СЕРТИФІКАТУ-----

Текст сертифіката HES IdP, який ви завантажили на попередньому кроці.

-----КІНЦЕВИЙ СЕРТИФІКАТ-----

# вийти

 

Крок 2. Надайте свій ідентифікатор SAML

# webvpn

# saml idp https://example.hideez.com/

# url-адреса для входу https://example.hideez.com/Saml/Login

# URL-адреса виходу https://example.hideez.com/Saml/Logout

# точка довіри idp HES-SAML - [IdP Trustpoint]

# trustpoint sp ASA-EXTERNAL-CERT - [SP Trustpoint]

# без примусової повторної автентифікації

# без підпису

# base-url https://asa.example.com

 

Крок 3. Застосуйте автентифікацію SAML до конфігурації тунелю VPN

# tunnel-group TUNNEL-GROUP-NAME webvpn-attributes

saml identity-provider https://example.hideez.com/

автентифікація saml

# end

# пам'ять запису

 

Крок 4 Отримати файл метаданих SAML ASA

Виконайте таку команду:

# показати метадані saml TUNNEL-GROUP-NAME

Потім скопіюйте текст метаданих у файл xml та збережіть його.

Примітка: якщо ви вносите зміни до конфігурації IdP, вам потрібно видалити конфігурацію постачальника ідентифікаційних даних saml зі своєї групи тунелів і повторно застосувати її, щоб зміни набули чинності.

 

Додайте постачальника послуг до HES

Увійдіть на сервер HES, потім перейдіть до Налаштування -> Параметри -> SAML. Потім натисніть кнопку [Додати постачальника послуг].

У наступній формі ви можете додати файл метаданих або заповнити всі параметри вручну:

  • Issuer - унікальне ім'я SP, яке потрібно скопіювати з налаштувань SP або витягти з файлу метаданих.
  • Assertion Consumer Service - адреса входу на стороні постачальника послуг. Перенаправлення здійснюється на цю адресу після успішного входу через службу IdP.
  • Послуга єдиного виходу - адреса для виходу з облікового запису. Якщо ви виходите з IdP, ця URL-адреса відкривається в циклі для всіх SP.
  • Public x509 Certificate - сертифікат відкритого ключа постачальника послуг.
  • Формат ідентифікатора імені - формат поля, що ідентифікує користувача.
  • Поле ідентифікатора імені - вибір поля, куди можна взяти ідентифікатор користувача.

Оскільки IdP і SP можуть використовувати різні ідентифікатори для користувачів, потрібен механізм узгодження цих ідентифікаторів для встановлення відповідності один до одного між користувачами в обох службах. Ідентифікатором користувача (логіном) у HES є його електронна адреса, хоча в інших системах це може бути щось інше (наприклад, комбінація імені та прізвища користувача).

Якщо ваша конфігурація ASA та AD приймає електронну пошту як ідентифікатор користувача, потрібно встановити:

Формат ідентифікатора імені – Поле ідентифікатора імені електронної пошти – Електронна адреса

Якщо конфігурація ASA та AD не приймає електронну пошту як ідентифікатор користувача, потрібно встановити формат, який ви використовуєте, у полі «Формат ідентифікатора імені», а значення «Зовнішній ідентифікатор» у полі «Ім’я». Поле ідентифікатора. Потім потрібно заповнити поле «Зовнішній ідентифікатор» для кожного співробітника. Для цього натисніть Співробітники -> "Вибрати співробітника -> Деталі -> Редагувати налаштування (у розділі Єдиний вхід) -> Змінити зовнішній ідентифікатор.

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

 

Остаточна перевірка

Крок 1. Увімкніть SSO для користувача в HES

Співробітники не можуть входити в службу HES і використовувати службу SSO за замовчуванням, вони повинні мати явний дозвіл адміністратора. Виберіть співробітника та натисніть кнопку [Редагувати]. Потім натисніть кнопку [Увімкнути SSO] на відкритій сторінці, щоб надати дозвіл.

Примітка: Співробітник повинен мати електронну адресу та пов’язаний ключ, щоб активувати службу SSO.

Послуга SSO вмикається автоматично і не може бути деактивована для всіх адміністраторів HES.

Якщо зовнішній ідентифікатор використовується як поле ідентифікатора імені, ви також повинні заповнити це поле. Відкрийте «Співробітники» -> «Виберіть співробітника» -> «Редагувати», щоб відредагувати поле зовнішнього ідентифікатора.

Деякі постачальники послуг можуть не підтримувати цю функцію.

Крок 2.Увійдіть до веб-служби за допомогою SAML

Підключіться до своєї URL-адреси VPN та виберіть один із варіантів входу у вікні Hideez Enterprise Server, а потім використовуйте свої облікові дані для входу:

AnyConnect підключено:

 

Поширені проблеми

1 НЕ ВІДПОВІДНІСТЬ ІДЕНТИФІКАЦІЙ ОБ'ЄКТИ

Приклад налагодження[SAML] consume_assertion: #LassoServer ідентифікатор постачальника невідомий. Щоб зареєструвати постачальника в об’єкті #LassoServer, ви повинні використовувати методи lasso_server_add_provider() або lasso_server_add_provider_from_buffer().

Проблема: Зазвичай означає, що команда saml idp [entityID] у конфігурації webvpn ASA не відповідає ідентифікатору об’єкта IdP, знайденому в Метадані IdP.

Рішення: Перевірте ідентифікатор сутності у файлі метаданих IdP та змініть команду saml idp [entity id], щоб вона відповідала цьому.

2. НЕВІДПІДНІСТЬ ЧАСУ

Приклад налагодження[SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout9 >

[SAML] consume_assertion: термін дії твердження минув або недійсний

Проблема 1. Час ASA не синхронізовано з часом IdP.

Рішення 1. Налаштуйте ASA з тим самим сервером NTP, що використовується IdP.

Проблема 2. Твердження недійсне між зазначеним часом.

Рішення 2. Змініть значення тайм-ауту, налаштованого на ASA.

3. ВИКОРИСТОВУЄТЬСЯ НЕПРАВИЛЬНИЙ СЕРТИФІКАТ СПІВАННЯ IDP

Приклад налагодження[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_Verify=Final1:er не збігаються:підпис не відповідає

[SAML] consume_assertion: профіль не може перевірити підпис у повідомленні

Проблема: ASA не може перевірити повідомлення, підписане IdP, або немає підпису для перевірки ASA.

Рішення: Перевірте сертифікат підпису IdP, встановлений на ASA, щоб переконатися, що він відповідає тому, що надсилається IdP. Якщо це підтверджено, переконайтеся, що підпис включено у відповідь SAML.

4. НЕДЕЙСТВУЄ АУДИТОРІЯ ТВЕРДЖЕННЯ

Приклад налагодження[SAML] consume_assertion: аудиторія твердження недійсна

Проблема: IdP визначає неправильну аудиторію.

Рішення: Виправте конфігурацію аудиторії на IdP. Він має відповідати ідентифікатору об’єкта ASA.

5. НЕПРАВИЛЬНА URL-адреса ДЛЯ ТВЕРДЖЕННЯ СЛУЖБИ КОНСУЛЬТАЦІЙ

Приклад налагодження: неможливо отримати будь-які налагодження після відправлення початкового запиту автентифікації. Користувач може ввести облікові дані в IdP, але IdP не перенаправляє на ASA.

Проблема: IdP налаштовано для неправильної URL-адреси служби підтримки споживачів.

Рішення: Перевірте базову URL-адресу в конфігурації та переконайтеся, що вона правильна. Перевірте метадані ASA за допомогою show, щоб переконатися, що URL-адреса Assertion Consumer Service правильна. Щоб перевірити його, перегляньте його, якщо обидва правильні в ASA, перевірте IdP, щоб переконатися, що URL-адреса правильна.

5. ЗМІНИ КОНФІГУРАЦІЇ SAML НЕ НАБИРАЮТЬ ДІЇ

Приклад: після того, як URL-адресу єдиного входу змінено або змінено, сертифікат SP, SAML все ще не працює та надсилає попередні конфігурації.

Проблема: ASA має відновити свої метадані, коли на нього впливає зміна конфігурації. Це не робиться автоматично.

Рішення: Після внесення змін видаліть і повторно застосуйте команду saml idp [entity-id] у відповідній групі тунелів.

 

Усунення несправностей

Більшість засобів усунення несправностей SAML пов’язані з неправильними налаштуваннями, які можна виявити під час перевірки конфігурації SAML або запуску налагодження debug webvpn saml 255 можна використовувати для усунення більшості проблем, однак у випадках, коли це налагодження не надає корисної інформації, можна запустити додаткові налагодження:

Потрібна допомога? Спробуйте пошукати в нашій статті Бази знань або зверніться до Служби підтримки для отримання додаткової допомоги.

 

 

 

.