Cordoned Sessions
verb
Google Dictionary
- prevent access to or from an area or building by surrounding it with police or other guards.”the city center was cordoned off after fires were discovered in two stores”
Managers can “cordon” sessions preventing users from connecting to sessions and making changes. Typical use cases include
- Preventing access to a session without termination
- Migrating the session to a different FastX login
- Mapping 1 FastX login to Many linux user logins across a heterogenous cluster
- Catastrophic session recovery in clusters running OpenID Connect/SAML logins or weblink proxies
In all these cases the session data being passed to the cluster cannot be initially trusted. Cordoned sessions are available to be viewed or terminated, but cannot be connected to until a manager reviews and “uncordons” the session.
Cordoned sessions are able to communicate with the web server to advertise their existence at the same time protecting users from accessing malicious sessions.
How to cordon a session
For typical sessions, the FastX login and the linux username match. In these cases sessions are verified using standard linux security and cordoning sessions is not necessary.
Manually cordoning a session
Managers can cordon running sessions to prevent new connections to the session. Managers may wish to secure a session from changes if for example there has been a security breach and the managers want to do a root cause analysis.
- Log in as a Manager or Admin
- Click on the Manage button
- Select a session
- From the Actions Menu choose Cordon
- Managers can optionally add a message to associate with the cordoned session.
Automatically cordoning a session
FastX logins that differ from the Linux username use JSON Web Tokens (JWT) verification to authenticate the session with the web server. These JWTs are called linkTokens and by default expire in 7 days. If a linkToken fails verification (cannot find the issuer, expired, bad token, token missing required claims, token does not exist, etc) the token is rejected and the session is automatically cordoned.
CORDON_SCRIPT
Staring in build 4.1.21, admins can set a CORDON_SCRIPT in fastx.env that will automatically decide whether to (un)cordon a connecting session. This allows admins to programmatically decide whether to accept or reject the connection as well as what state to put the session in
STDIN
The script takes a JSON stdin object with the payload of the JWT (and extra claims). Typical options include.
{
"sub": "sessionID",
"fastx/login": "fastx login name",
"fastx/cordon": true // is the session cordoned (eg token was expired)
"fastx/cordon-message": "Optional text message"
}
STDOUT
The script interpret any stdout as the new fastx/login to associate with the session
EXIT CODES
- 0 — accept the session and uncordon it
- 1 — default action, cordon or uncordon it according to standard conditions
- 2 — reject the session and close the connection
- > 2 — cordon the session (set stderr to fastx/cordon-message)