Перейти до вмісту
SSO: що таке система єдиного входу? Універсальна служба SSO для підприємств
Зміст
Недоліки та переваги системи єдиного входу
Приклади системи єдиного входу
Універсальна служба єдиного входу від Hideez
Приклад налаштування ASA AnyConnect VPN для Hideez Enterprise Server через SAML
Налаштування ASA для SAML через CLI
Додайте постачальника послуг до HES
Під час входу в додатки чи веб-сайти ви, мабуть, бачили можливість входу за допомогою Facebook або Google. Магічним чином вони дозволяють входити на сторонні веб-сайти, навіть не створюючи обліковий запис.
Це не магія, а технологія єдиного входу або SSO (single sign-on). Що це таке, як це працює і чому так багато сучасних організацій використовують його з міркувань безпеки?
Що означає SSO і як це працює
Єдиний вхід — це процес автентифікації, який дозволяє користувачам отримувати доступ до кількох сервісів за допомогою одного набору облікових даних для входу, наприклад логіна та пароля. Це означає, що коли користувач увійшов у систему, йому не потрібно повторно входити в кожний сервіс, пов’язаний з цією системою.
Насправді єдиний вхід — це об’єднана угода про керування ідентифікацією між трьома об’єктами:
- Користувачі (Users) — Окремим людям потрібен доступ до різних служб. Вони повинні мати можливість керувати особистою інформацією, такою як свій логін або пароль, і їх має бути однозначно ідентифікованою.
- Постачальники послуг (Service Provider, SP) — Традиційно це веб-сайти та програми, до яких користувачі хочуть отримати доступ, але вони можуть включати всілякі продукти та послуги, такі як доступ Wi-Fi, ваш телефон або пристрої «Інтернету речей».
- Постачальники ідентифікаційних даних (Identity Provider, IdP) — Бази даних, що зберігають ідентифікаційні дані користувачів, які потім можна об’єднати з різними ІТ-ресурсами. Вони також можуть зберігати багато екземплярів ідентичності користувача, які містять таку інформацію, як імена користувачів, паролі, ключі SSH, біометричну інформацію та інші атрибути. Одним із найпопулярніших постачальників ідентифікаційних даних сьогодні є Microsoft Active Directory, розроблена для керування іменами користувачів і паролями Windows і підключення їх до локальних ІТ-ресурсів Windows.
Для того, щоб система SSO працювала, більшість програм покладаються на відкриті стандартні протоколи, щоб визначити, як постачальники послуг і постачальники ідентифікаційної інформації можуть обмінюватися ідентифікаційною інформацією та інформацією автентифікації один з одним. Найпоширенішими протоколами є SAML , OAuth і OpenID Connect (OIDC), які безпечно дозволяють одній службі отримувати доступ до даних іншої.
Сьогодні ми бачимо тенденцію, яку починають усвідомлювати компанії: віддалена робота з дому означає, що більше користувачів мають входити у свої облікові записи через Інтернет, щоб отримати доступ до важливої інформації. І це ціла нова сфера потенційних векторів атак. Злочинці це вже знають і цим користуються. Тому все більше і більше компаній починають боротися з цими новими загрозами, впроваджуючи рішення SSO.
Недоліки та переваги системи єдиного входу
Основною перевагою SSO є чудова взаємодія з користувачами і зручність, яку вона їм надає. Користувачі мають мінімум паролів, які потрібно запам’ятати: це спрощує процес входу та зменшує ймовірність фішингу.
Система єдиного входу особливо корисна для компаній, які працюють віддалено через COVID-19, оскільки служби єдиного входу забезпечують найбільш безпечну та зручну автентифікацію для віддаленого входу. Використання системи єдиного входу також може бути частиною інтегрованої системи керування доступом для швидше надання та відключення користувачів.
З іншого боку, SSO створює ризики, оскільки створює "єдину точку збою" (single point of failure), якою можуть скористатися зловмисники, щоб отримати доступ доо інших програм. Крім того, як і багато ІТ-інструментів, 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, і користувач автоматично перенаправляється на сервер Hideez;
Крок 3. Користувачеві пропонується заповнити дані для входу або вибрати один із доступних методів автентифікації: апаратний ключ безпеки (Yubikey, багатофункціональний Hideez Key або будь-який інший апаратний ключ безпеки), або мобільний додаток Hideez Authenticator;
Крок 4. Сервер Hideez надсилає результат автентифікації постачальнику послуг і перенаправляє користувача назад до початкової програми.
Крок 5. Користувач проходить автентифікацію, ймовірно, нічого не помічаючи, за винятком кількох викликів перенаправлення в рядку URL-адреси його браузера.
Універсальна служба єдиного входу від Hideez
Служба єдиного входу Hideez — це постачальник ідентифікаційних даних SAML (IdP), який додає систему єдиного входу до Windows Active Directory за допомогою об’єднання SAML 2.0. Адміністратори можуть налаштувати єдиний вхід для будь-якої веб-або мобільної програми, яка підтримує стандарти OpenID Connect або SAML. І окрім цього до цього, ми робимо SSO повністю безпарольною!
На відміну від системи єдиного входу з традиційними логінами на основі пароля, система єдиного входу Hideez може усувати паролі та замінювати їх на безпарольну автентфиікацію через мобільний додаток, де це можливо. Навіть якщо деякі з ваших програм не підтримують стандарти SAML або OIDC і не можуть бути повністю безпарольними, ви можете використовувати ключ Hideez Key як апаратний менеджер паролів і автоматично заповнювати облікові дані для входу одним натисканням кнопки.
Ви можете вибрати будь-який фактор автентифікації, який є найбільш зручним для ваших співробітників:
- Смартфони. Hideez Authenticator — це додаток з функцією SSO для пристроїв Android та iOS. Він може перетворити смартфони користувачів на безпарольні токени, які замінюють їхні логіни і паролі безпечним входом на основі одноразових QR-кодів за допомогою біометричної перевірки або перевірки PIN-коду на смартфоні кінцевого користувача
- Апаратні ключі безпеки. Ключі Hideez Key — це багатофункціональні пристрої Bluetooth/NFC/USB, захищені PIN-кодом. Ви можете використовувати їх для безпарольного входу в різноманітні служби на основі стандарту FIDO2, зберігати облікові дані для входу на основі пароля, генерувати одноразові паролі для двофакторної автентифікації і навіть блокувати або розблоковувати комп’ютери Windows на основі близькості ключа.
Hideez Enterprise Server інтегрується з системами ідентифікації Microsoft Active Directory, Azure Active Directory і LDAP, щоб спростити адаптацію та керування користувачами . Ваші співробітники можуть використовувати систему єдиного входу для доступу до будь-яких сервісів, що робить службу Hideez SSO надзвичайно зручною для користувачів. Не кажучи вже про те, що вам не потрібно запам’ятовувати облікові дані або думати про запобігання фішингу та крадіжці особистих даних.
Hideez перевершує всіх поточних конкурентів за зручністю та ціною, пропонуючи повну відповідність стандартам безпеки даних та автентифікації, таким як GDPR, NIST, PSD2, PSI-DSS і HIPAA. Вживаючи запобіжних заходів завчасно, ви можете заощадити багато грошей і часу в довгостроковій перспективі.
Заплануйте демонстрацію або подайте запит на безкоштовну 30-денну пробну версію Hideez SSO та долучайтеся до безпарольного майбутнього!
Приклад налаштування ASA AnyConnect VPN для Hideez Enterprise Server через SAML
Hideez Enterprise Server (HES) підтримує стандарт SAML 2.0 (Security Assertion Markup Language) для автентифікації користувачів. HES — це IdP (Identity Provider), який увімкне 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, якщо міститься інформація для Single Sign-On IdP, або SPSSODescriptor, якщо міститься інформація для Single Sign-On SP. Це важливо, оскільки для успішного налаштування SAML потрібні правильні значення з відповідних розділів.
Ідентифікатор організації: Це поле є унікальним ідентифікатором для SP або IdP. Один пристрій може мати кілька служб і використовувати різні ідентифікатори об’єктів, щоб їх розрізняти. Наприклад, ASA має різні ідентифікатори об’єктів для різних тунельних груп, які потребують автентифікації. IdP, який автентифікує кожну групу тунелів, має окремі записи ідентифікатора об’єкта для кожної групи тунелів, щоб точно ідентифікувати ці служби.
ASA може підтримувати кілька IdP і має окремий ідентифікатор об’єкта для кожного IdP, щоб їх розрізняти. Якщо будь-яка сторона отримує повідомлення від пристрою, який не містить ідентифікатора об’єкта, який був налаштований раніше, пристрій, імовірно, видалить це повідомлення, і автентифікація SAML стане невдалою. Ідентифікатор об’єкта можна знайти в полі EntityDescriptor поруч із ідентифікатором об’єкта.
URL-адреси служби: Вони визначають URL-адресу служби SAML, яку надає SP або IdP. Для IdP це найчастіше служба єдиного виходу з системи та служба єдиного входу. Для постачальників послуг це, як правило, Assertion Consumer Service і Single Logout Service.
URL-адреса служби єдиного входу, знайдена в метаданих IdP, використовується SP для перенаправлення користувача до IdP для автентифікації. Якщо це значення налаштовано неправильно, IdP не отримує або не може успішно обробити запит на автентифікацію, надісланий SP.
URL-адреса Assertion Consumer Service, знайдена в метаданих 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 як IdP
Крок 1. Установіть параметри постачальника ідентифікаційної інформації
Ідентифікатори та постачальники послуг повинні обмінюватися сертифікатами відкритих ключів, адресами для запитів та іншими параметрами для встановлення згоди між ними.
Для роботи протоколу SAML необхідний сертифікат у форматі «.pfx». Його можна створити, наприклад, за допомогою програми OpenSSL або за допомогою наявного сертифіката. Файл сертифіката потрібно скопіювати на сервер HES (наприклад, папку з бінарними файлами та налаштуваннями).
Увійдіть на сервер HES, потім перейдіть до Налаштування -> Параметри -> SAML. Потім натисніть кнопку [Set IdP Settings]:
Виберіть свій файл .pfx і введіть пароль для нього. Також потрібно вибрати відповідний алгоритм:
SignatureAlgorithm - алгоритм підпису. Він має відповідати алгоритму, за яким було встановлено сертифікат pfx. Можливі варіанти: SHA1, SHA256, SHA384, SHA512.
Крок 2. Отримайте файл метаданих HES
На цій же сторінці (Налаштування -> Параметри -> SAML), після встановлення сертифіката .pfx, ви можете:
- Переглянути метадані · Завантажити метадані · Завантажити сертифікат відкритого ключа
Метадані — це файл XML, який містить усю необхідну інформацію про налаштування IdP і сертифікат відкритого ключа. ASA дозволяє імпортувати метадані IdP під час налаштування SAML, що спрощує налаштування. Ви також можете завантажити окремий сертифікат, якщо це необхідно, або переглянути всі метадані на екрані.
Для наступних кроків вам потрібно завантажити файл метаданих і файли сертифікатів.
Налаштувати ASA для SAML через CLI
Крок 1. Створіть точку довіри та імпортуйте наш сертифікат SAML
# конфігурація t
# crypto ca trustpoint HES-SAML
відкликання перевірки немає
ідентифікатор не використовується
термінал реєстрації
без ca-check
# crypto ca authenticate HES-SAML
-----ПОЧАТОК СЕРТИФІКАТУ-----
…
Текст сертифіката HES IdP, який ви завантажили на попередньому кроці.
…
-----КІНЕЦЬ СЕРТИФІКАТУ-----
# вийти
Крок 2. Надайте свій SAML IdP
# 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 sp ASA-EXTERNAL-CERT - [SP Trustpoint]
# без примусової повторної автентифікації
# немає підпису
# базова URL-адреса https://asa.example.com
Крок 3. Застосуйте автентифікацію SAML до конфігурації тунелю VPN
# tunnel-group TUNNEL-GROUP-NAME webvpn-attributes
saml identity-provider https://example.hideez.com/
автентифікація saml
# кінець
# пам'ять запису
Крок 4 Отримайте файл метаданих SAML ASA
Виконайте таку команду:
# показати метадані saml TUNNEL-GROUP-NAME
Потім скопіюйте текст метаданих у файл xml і збережіть його.
Примітка: якщо ви вносите зміни в конфігурацію IdP, вам потрібно видалити конфігурацію постачальника ідентифікаційної інформації saml із групи тунелів і повторно застосувати її, щоб зміни набули чинності.
Додайте постачальника послуг до HES
Увійдіть на сервер HES, потім перейдіть до Налаштування -> Параметри -> SAML. Потім натисніть кнопку [Додати постачальника послуг].
У наступній формі ви можете додати файл метаданих або заповнити всі параметри вручну:
- Емітент – унікальне ім’я SP, яке потрібно скопіювати з налаштувань SP або витягти з файлу метаданих.
- Assertion Consumer Service - адреса входу на стороні постачальника послуг. Переспрямування здійснюється на цю адресу після успішного входу через службу IdP.
- Single Logout Service - адреса для виходу з облікового запису. Якщо ви виходите з IdP, ця URL-адреса відкривається в циклі для всіх SP.
- Відкритий сертифікат x509 - сертифікат відкритого ключа постачальника послуг.
- Формат ідентифікатора імені - формат поля, яке ідентифікує користувача.
- Поле ідентифікатора імені - вибір поля, куди можна взяти ідентифікатор користувача.
Оскільки IdP і SP можуть використовувати різні ідентифікатори для користувачів, необхідний механізм зіставлення цих ідентифікаторів, щоб встановити однозначну відповідність між користувачами в обох службах. Ідентифікатором користувача (логіном) у HES є його електронна адреса, хоча в інших системах це може бути щось інше (наприклад, комбінація імені та прізвища користувача).
Якщо ваша конфігурація ASA та AD приймає електронну пошту як ідентифікатор користувача, вам потрібно встановити:
Формат ідентифікатора імені - Поле ідентифікатора імені електронної пошти - Електронна адреса
Якщо конфігурація ASA та AD не приймає електронну пошту як ідентифікатор користувача, вам потрібно встановити формат, який ви використовуєте, у полі «Формат ідентифікатора імені» та значення «Зовнішній ідентифікатор» у полі «Ім’я». Поле ідентифікатора. Потім потрібно заповнити поле «Зовнішній ідентифікатор» для кожного співробітника. Для цього натисніть Employees -> 'Select an Employee -> Details -> Edit settings (у розділі Single Sign On) -> Edit the External ID.
Після заповнення та збереження всіх налаштувань ви можете перевірити інтеграцію, увійшовши до постачальника послуг. Вас має бути перенаправлено на сторінку автентифікації HES, де вам потрібно буде ввести своє ім’я користувача (електронну адресу) і пройти перевірку ключа безпеки.
Остаточна перевірка
Крок 1. Увімкніть SSO для користувача в HES
Співробітники не можуть увійти в службу HES і використовувати службу 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 [ідентифікатор об’єкта] відповідно до цього.
2. НЕВІДПОВІДНІСТЬ ЧАСУ
Приклад налагодження: [SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout: 0
[SAML] consume_assertion: твердження прострочено або недійсне
Проблема 1. Час ASA не синхронізується з часом IdP.
Рішення 1. Налаштуйте ASA з тим самим NTP-сервером, який використовується IdP.
Проблема 2. Твердження недійсне між вказаним часом.
Рішення 2. Змініть значення часу очікування, налаштоване на ASA.
3. ВИКОРИСТАНО НЕПРАВИЛЬНИЙ СЕРТИФІКАТ ВПО ВПО
Приклад налагодження: [Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data не збігаються:підпис не збігається
[SAML] consume_assertion: профіль не може перевірити підпис у повідомленні
Проблема: ASA не може перевірити повідомлення, підписане IdP, або немає підпису для перевірки в ASA.
Рішення: Перевірте сертифікат підпису IdP, установлений на ASA, щоб переконатися, що він відповідає тому, що надсилає IdP. Якщо це підтверджено, переконайтеся, що підпис включено у відповідь SAML.
4. АУДИТОРІЯ НЕВІДПОВІДНОГО ЗАЯВЛЕННЯ
Приклад налагодження: [SAML] consume_assertion: аудиторія твердження недійсна
Проблема: IdP визначає неправильну аудиторію.
Рішення: Виправте конфігурацію аудиторії на IdP. Він має відповідати ідентифікатору організації ASA.
5. НЕПРАВИЛЬНА URL-адреса ДЛЯ ОБСЛУГОВУВАННЯ СПОЖИВАЧІВ
Приклад налагодження: неможливо отримати жодних налагоджень після надсилання початкового запиту автентифікації. Користувач може ввести облікові дані в IdP, але IdP не перенаправляє до ASA.
Проблема: IdP налаштовано для неправильної URL-адреси Assertion Consumer Service.
Рішення: Перевірте базову URL-адресу в конфігурації та переконайтеся, що вона правильна. Перевірте метадані ASA за допомогою show, щоб переконатися, що URL-адреса обслуговування споживачів Assertion правильна. Щоб перевірити його, перегляньте його, якщо обидва правильні на ASA, перевірте IdP, щоб переконатися, що URL правильний.
5. ЗМІНИ КОНФІГУРАЦІЇ SAML НЕ ЗАСТОСОВУЮТЬСЯ
Приклад: після того, як URL-адресу єдиного входу змінено або змінено, сертифікат SP, SAML усе ще не працює та надсилає попередні конфігурації.
Проблема: ASA має відновити свої метадані, коли відбувається зміна конфігурації, яка впливає на це. Це не робиться автоматично.
Рішення: Після внесення змін у відповідній тунельній групі видаліть і повторно застосуйте команду saml idp [entity-id].
Усунення несправностей
Більшість усунення несправностей SAML включає неправильну конфігурацію, яку можна виявити під час перевірки конфігурації SAML або запуску налагодження debug webvpn saml 255 можна використовувати для усунення більшості проблем, однак у сценаріях, коли це налагодження не надає корисної інформації, можна запустити додаткові налагодження:
Потрібна допомога? Спробуйте здійснити пошук у статтях бази знань або зверніться до служби підтримки для отримання додаткової допомоги.
.