Доступ через портал 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 — документ, который нужно прочитать до принятия обязательств, потому что границы зависят от версии.
Проверяйте важные потоки, а не посадочную страницу: войдите, пройдите каждую нужную функцию, загрузите файлы, если приложение это делает, дайте предполагаемому сеансу истечь и пройдите каждый путь выхода. Страница, отрисованная один раз, не доказывает, что приложение работает.
Когда требуемый поток нельзя перезаписать, переходите к документированному проекту федерации, обратного прокси или сетевого доступа. Браузерный портал, от которого требуют вести себя как общий туннель, пройдёт демонстрацию и провалит аудит.