Original concept illustration of membership removed, old session, download link. No product screenshot.
Original editorial concept illustration by Fone.

Removing a portal member needs to change the server's next access decision. The person's browser may still have an open page, a valid session cookie and a previously issued download link. Review each path that can continue delivering data after the membership change.

This is a focused revocation design for the unimplemented SaaS & Client Portal Foundation blueprint. It expands the general SaaS foundations discussion with specific request and download checks. The worksheet describes proposed deployment tests, all marked Not run.

Name the state that has been revoked

Distinguish removing one workspace membership from disabling the user's entire account. A person who belongs to two workspaces may need to retain access to the second. Record the scope of the revocation and which permissions it removes before deciding whether to end every session.

OWASP recommends checking permissions on every request. Apply that requirement to the next document read and export request, including requests made directly to an endpoint. Hiding the workspace in navigation does not supply the server with a current authorization decision. OWASP authorization guidance.

For the proposed design, membership changes receive a revision. Protected requests compare against the current membership authority before serving data. If the system caches that authority, the implementation needs an agreed propagation rule and a measured bound. No particular revocation delay is claimed here.

Review sessions separately from membership

A session establishes the identity used for a request. The server still has to evaluate that identity's access to the selected workspace. Decide which revocations invalidate the entire session and which simply remove one workspace from the available set.

OWASP's session guidance calls for server-side expiration enforcement, including idle and absolute timeouts. It also requires server-side invalidation when a session is terminated. These mechanisms help define session lifetime, but a long remaining lifetime should not silently preserve a revoked membership. Session management guidance.

Access path Proposed decision after removal Evidence to capture
New API request Deny protected workspace access Server decision and membership revision
Warm response cache Check current permission before serving Cache-hit request result
Queued export Recheck permission before delivery Job and delivery decision
Existing download link Apply its documented expiry or revocation mechanism Link behavior after removal
Open browser page Remove active views when informed UI behavior and next server request

Revocation timeline showing membership removal followed by server checks, session policy and separate download-link expiry

Treat download links as their own access path

Amazon S3 presigned URLs use the credentials of the principal that created them. The documentation says a URL can be used repeatedly until it expires, and that expiration can occur earlier when its underlying credentials expire or are revoked. Removing a portal membership does not itself change those signing credentials. S3 presigned URL behavior.

For sensitive files, compare a short-lived direct URL with delivery through an application endpoint that checks current membership. The latter gives the application another request-time decision, while introducing its own delivery and operating requirements. Choose based on the required revocation behavior and actual storage setup.

Record what happens to an export that was authorized before removal but has not yet been delivered. The proposed policy checks authorization again at delivery. If the job has already produced a file, keep its visibility separate from its existence in storage.

Inspect cached and already-delivered data

HTTP no-store controls cache storage for the covered exchange. It cannot retrieve bytes the user has already downloaded. Define the acceptance criterion around future access that the service controls, and describe separately how the interface handles an open page. HTTP cache directives.

A push message can tell the browser that access changed and clear the visible workspace. Treat that as interface behavior. The decisive negative test sends a protected request with the old session even if the browser never receives the message.

Plan the test with two workspaces, an active session and a prepared export. Remove membership in one workspace while leaving the other intact. Attempt an old API request, open the existing download URL and resume the export job. Record each outcome independently, including any documented period during which the direct URL remains usable.

Download the portal revocation worksheet to assign these decisions to owners and collect evidence. Its blank results should remain Not run until a chosen deployment is exercised.

The SaaS & Client Portal Foundation blueprint can scope these controls around your workspace model. Bring the session architecture, file-delivery path and required revocation timing to the implementation review.