APM Portal Access: Who Owns the Application Session?
Five checks for a BIG-IP Portal Access publishing decision: resource scope, backend session, two timers, logout meaning and rewriting limits.
Publishing an intranet app through BIG-IP APM Portal Access is a decision about sessions, not about copying a virtual server. The portal admits the user, the rewrite profile keeps selected requests on the gateway path, and the application still owns a session of its own. Five checks separate a design that behaves predictably from one where the help desk learns about timeouts one user at a time. Work them in order and stop at the first one that is not true.
Check 1: the resource is published, not just linked
A webtop bookmark proves that a user can see an entry. It does not prove that the application is published. Look for the access profile, the rewrite profile and the virtual server that combines them, then confirm the resource assignment points at the application you think it does. If any of those three is missing or inconsistent, the rest of this list is moot.
The half-published case looks healthy at the entry point. A virtual server carries the access profile while the rewrite profile is scoped to a different resource URI, so the webtop entry appears and the first page loads, then the sub-path requests leave the gateway path and reach the backend directly. The mirror image is a resource assigned to the wrong application: the bookmark opens, and it opens something nobody approved.
Check 2: the backend session is a separate state
The backend can require its own authentication even while APM considers the user signed in. A supported SSO integration establishes that relationship for you, but accepting the portal login does not make every application accept the same credentials or the same session cookie. If SSO is not configured for the resource, the application will ask for its own login inside an already authenticated portal.
Disabling SSO to change the visible prompt is a common shortcut and a poor one: it alters the authentication design without touching the lifecycle that produced the prompt. Decide instead whether the backend login should appear at all, and if it should, make that an explicit part of the published flow.
Check 3: there are two clocks, and they are not the same clock
APM's access profile carries an inactivity timeout and a maximum session lifetime. The application carries its own idle timer and cookie expiry. Raising a portal timer does not extend an application session, and shortening an application session does not log the user out of the portal.
| 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 |
The classic support call follows from a mismatched pair: the portal is still valid, the application session is not, and the user sees a login form that appears to contradict the portal. That is correct behaviour, not a fault, and the fix is to choose which clock should expire first for this application.
Check 4: logout has a defined scope
Write down what the application's sign-out button should end: that application only, the whole APM session, or a wider identity-provider session. The access profile supports a logout URI list with an optional delay, which is how you make the application's logout terminate the portal session when that is the requirement. Without it, an application logout leaves the portal alive, and a subsequent request can silently sign the user back in.
Account for the effect on other resources in the same portal. If logging out of one application ends the session for six others, users will call that a bug unless the behaviour was agreed with the application owner first. Closing a tab and returning to the webtop are not proof that anything ended.
Check 5: the application survives rewriting
Portal Access rewrites selected web content, and rewriting has edges. Modern client-side features, background workers, upload flows and federated login can land outside what a given release handles. F5's versioned compatibility matrix is the document to read before committing, because the limits are release-specific.
Test the flows that matter rather than the landing page: sign in, navigate each required function, upload if the app uploads, let the intended session expire, and follow every logout path. A page that renders once is not evidence that the application works.
When a required flow cannot be rewritten, move to a documented federation, reverse-proxy or network-access design. A browser portal asked to behave like a general tunnel will pass the demo and fail the audit.