Доступ через портал APM: кому належить сеанс застосунку?
П'ять перевірок для рішення про публікацію з BIG-IP Portal Access: обсяг ресурсу, сеанс backend, два таймери, сенс виходу та межі перезапису.
Публікація інтранет-застосунку через BIG-IP APM Portal Access — це рішення про сеанси, а не про копіювання віртуального сервера. Портал впускає користувача, профіль перезапису утримує вибрані запити на шляху шлюзу, а застосунок досі має власний сеанс. П'ять перевірок відокремлюють проєкт, що поводиться передбачувано, від того, де служба підтримки дізнається про тайм-аути користувач за користувачем. Пройдіть їх по порядку і зупиніться на першій, яка не відповідає дійсності.
Перевірка 1: ресурс опубліковано, а не просто пов'язано
Закладка в webtop доводить, що користувач бачить запис. Вона не доводить, що застосунок опубліковано. Знайдіть профіль доступу, профіль перезапису і віртуальний сервер, який їх поєднує, потім підтвердьте, що призначення ресурсу вказує на застосунок, про який ви думаєте. Якщо чогось із цих трьох бракує або воно суперечливе, решта списку не має сенсу.
Випадок напівпублікації виглядає здоровим на вході. Віртуальний сервер несе профіль доступу, тоді як профіль перезапису обмежений іншим URI ресурсу, тому запис у webtop з'являється і перша сторінка завантажується, а далі запити підшляху залишають шлях шлюзу і доходять до backend напряму. Дзеркальна картина — ресурс, призначений не тому застосунку: закладка відкривається і відкриває те, чого ніхто не затвердив.
Перевірка 2: сеанс backend — окремий стан
Backend може вимагати власної автентифікації навіть тоді, коли APM вважає користувача автентифікованим. Підтримувана інтеграція SSO встановлює цей зв'язок за вас, але прийняття входу в портал не робить так, що кожен застосунок приймає ті самі облікові дані чи той самий cookie сеансу. Якщо SSO не налаштовано для ресурсу, застосунок запросить власний вхід усередині вже автентифікованого порталу.
Вимкнення SSO заради зміни видимого запиту — поширений і поганий обхідний шлях: він змінює проєкт автентифікації, не торкаючись життєвого циклу, який породив запит. Натомість вирішіть, чи має вхід до backend узагалі з'являтися, і якщо має, зробіть його явною частиною опублікованого потоку.
Перевірка 3: є два годинники, і це не той самий годинник
Профіль доступу APM несе тайм-аут неактивності та максимальний час життя сеансу. Застосунок несе власний таймер простою та закінчення терміну cookie. Збільшення таймера порталу не подовжує сеанс застосунку, а скорочення сеансу застосунку не виводить користувача з порталу.
| Timer | Owner | What it ends |
|---|---|---|
| Inactivity timeout | APM access profile | the portal session after idle time |
| Maximum lifetime | APM access profile | the portal session regardless of activity |
| Application cookie | Backend application | the application session inside a live portal |
Класичний дзвінок до підтримки виникає з неузгодженої пари: портал ще дійсний, сеанс застосунку — ні, і користувач бачить форму входу, яка ніби суперечить порталу. Це правильна поведінка, а не збій, і рішення — вибрати, який годинник для цього застосунку має спливти першим.
Перевірка 4: вихід має визначений обсяг
Запишіть, що має завершувати кнопка виходу застосунку: лише цей застосунок, увесь сеанс APM або ширший сеанс постачальника ідентичності. Профіль доступу підтримує список URI виходу з необов'язковою затримкою, і саме так вихід із застосунку завершує сеанс порталу, коли це вимога. Без цього вихід із застосунку залишає портал живим, і наступний запит може мовчки знову впустити користувача.
Врахуйте вплив на інші ресурси того самого порталу. Якщо вихід з одного застосунку завершує сеанс ще шести, користувачі назвуть це помилкою, якщо поведінку не було узгоджено заздалегідь із власником застосунку. Закриття вкладки й повернення до webtop не доводять, що щось завершилося.
Перевірка 5: застосунок переживає перезапис
Portal Access перезаписує вибраний веб-вміст, і в перезапису є межі. Сучасні клієнтські функції, фонові процеси, потоки завантаження та федеративний вхід можуть опинитися поза тим, що обробляє конкретна версія. Матриця сумісності за версіями від F5 — документ, який треба прочитати перед зобов'язанням, бо межі залежать від версії.
Тестуйте важливі потоки, а не посадкову сторінку: увійдіть, пройдіть кожну потрібну функцію, завантажте файли, якщо застосунок це робить, дайте запланованому сеансу спливти й пройдіть кожен шлях виходу. Сторінка, відрендерена один раз, не доводить, що застосунок працює.
Коли потрібний потік не можна перезаписати, переходьте до задокументованого проєкту федерації, зворотного проксі або мережевого доступу. Браузерний портал, від якого вимагають поводитися як загальний тунель, пройде демонстрацію і провалить аудит.