User Tools

Site Tools


wiki:advanced:x2gobroker:howitworks

How does X2Go Session Brokerage Work?

Provided by Oleksandr Shneyder, edited by Mike Gabriel

This is about how X2Go Client and a generic X2Go Session Broker communicate with each other. This article will quickly become rather technical.

Authentication

X2Go Client in broker mode will authenticate twice. First, it will authenticate against the X2Go Session Broker, second, it will authenticate against one of the servers provided by the broker in form of X2Go session profiles. Dual authentication means: the user has to type his/her username and password twice.

A gain in usability cerainly is, if one manages to reduce these two authentication requests to one. How this can be achieved will be explained further below.

Authentication methods against X2Go Session Broker

In general, X2Go client can use different methods for authentication against an X2Go Session Broker.

With an HTTP(S) broker it could be username and password. With an SSH broker a SSH key based authentication is also possible.

Authentication methods against provided X2Go Servers

For authentication against X2Go Servers, SSH is used. With SSH you can use username and password authentication, SSH key authentication, GnuPG-Smartcard based authentication, etc.

Extra Security: Pre-shared Authentication ID

With both session broker types (HTTP, SSH) you can use an additional parameter authid. The authentication ID is used for verifying the trust state of an authenticating user/machine. The authentication ID is a user defined string (like a pre-shared key) which is stored in a file on the client-side.

The file path to the authentication ID has to be specified as the X2Go Client command line option --auth-id.

The usage of this feature is optional.

Don't Check User Data

In some setups it can make sense to give access to the X2Go Session Broker without authentication. This is one way of reducing the dual authentication steps to one (and thus increase usability of X2Go Client in broker mode).

Example: One possible example can be a session broker on your internal LAN where the broker only serves as a load balancer for two or more X2Go Servers (multi-node setup). For such a setup, it requires that all client machines on your LAN are trusted.

When implementing your own session broker, you can configure the broker not to check the username (and password) at all. This is only possible with HTTP based brokers.

With SSH based X2Go Session Broker implementations, you can also ignore the username, but it is not possible to access the broker without some sort of authentication method.

Granting Access to the Broker

Whatever mechanism is used for authentication, the first line printed to STDOUT (or returned via CGI script) has to be: Access granted.

This is to let X2Go Client know, that authentication has been successful.

List of predefined X2Go session profiles

After successful authentication against the X2Go Session Broker, X2Go Client will request a list of predefined X2Go session profiles. This session profile list looks pretty much the same as the sessions file of X2Go Client. Check ~/.x2goclient/sessions (under GNU/Linux) for reference.

Generic function: listSessions

A generic function, that sends X2Go session profiles to X2Go Client can look like this:

sub listSessions
{
  print "START_USER_SESSIONS\n
\n
[  <session 1>  ]\n
option1=value1\n
....
optionN=valueN\n
 
[  <session 2>  ]\n
option1=value1\n
....
optionN=valueN\n
\n
END_USER_SESSIONS\n";
}

Session Profile Format

The option keys and values are the same as in X2Go Client's configuration file (~/.x2goclient/sessions).

The only difference occurs in the parameters host=<hostname> and key=<keyfile>.

Furthermore, there are two extra parameters that are not supported in the sessions file, but have a special functionality when X2Go Client is run in broker mode: status={R,S} and usebrokerpass={true,false}.

The session profile option: host

The host= parameter is not necessarily a hostname of an X2Go Server. The actual address of the server will be provided after the session profile has been selected by the user. Delaying the provision of the X2Go Server name makes sense in a cases where X2Go Session Broker is used as a load balancer.

In load balancing setups, the best server will be chosen after selection of a session profile. Once the best server has been detected, it is sent to X2Go Client and X2Go Client uses this best server's hostname for authentication and session startup.

When resuming an X2Go session, the broker will know the server that runs the suspended session and return that one, so that the user can continue his/her earlier session.

The session profile option: key

The key= parameter is simply ignored when returned via an X2Go Session Broker.

A valid SSH key (X2Go Client authenticates against X2Go Servers using SSH) can be provided to X2Go Client directly after the selection of a session profile.

However, you can set this parameter with some value to inform the Client, that passwordless authentication should be tried, for example: key=will-be-provided-later.

The session profile option: usebrokerpass

The parameter usebrokerpass={true,false} is used to denote that requesting the user password for this session is not necessary, but that the X2Go Client should rather use the broker's username and password tuple instead.

This can be useful if the X2Go Session Broker and the X2Go Server use the same authentication server (e.g. same LDAP db) and there is no need to ask the same password twice.

It is highly recommended to only use this feature on HTTPS brokers (i.e. with SSL encryption for the X2Go Client ↔ X2Go Session Broker communication) or SSH brokers.

The session profile option: status

The parameter status={S,R} can be one of two values “S” or “R”. It can be used to tell X2Go Client that an instance (or instances) of this session profile are already running or are suspended on the server.

X2Go Client will display the status on the session profile card.

Selecting a Session Profile

After login to the X2Go Session Broker a list of provided session profiles is shown in X2Go Client. The user can now choose one session profile from this list. The ID of the chosen session profile will be sent to the session broker and the broker sends the connection data back to X2Go Client.

Generic function: selectSessions

This is a generic example for the “selectSession” function in a Perl based X2Go Session Broker:

sub selectSession
{
  my ($user, $sid)=@_;
  if($sid eq "123456789")
  {
      print "SERVER:x2goserver.org:22\n";
  }
}

This function sends a server address and an SSH port for the X2Go server connection back to X2Go Client.

Starting vs. Resuming X2Go Sessions

If no other data is specified, a new X2Go session will be created.

The X2Go Session Broker can also send information back to X2Go Client, that tells the client to resume a suspend session.

In the code example below, additionally to the X2Go Server hostname, X2Go Session Broker sends a session information line to X2Go Client. This session information line looks just the same as one of those lines that get returned by the X2Go Server command x2golistsessions:

sub selectSession
{
  my ($user, $sid)=@_;
  if($sid eq "123456789")
  {
      print "SERVER:phoca:22\n";
      print
"SESSION_INFO:12542|ncryer-53-1348753256_stDstartxfce4_dp24|53|debian|S|2012-09-27T06:40:57|7db77095d8a782f479d509d96f2e3261|188.195.168.12|30004|30005|2012-09-27T06:41:28|ncryer|285|30006|\n";
}

The X2Go Session Broker can get this data from the X2Go session database or by executing

x2golistsessions

under the requesting user ID on the X2Go Server.

No Auto-Resuming of Sessions

If X2Go Client is running in broker mode, it will not verify if there are existing sessions on the targeted X2Go Server.

Checking for running/suspended sessions is the responsibility of the X2Go Session Broker. The X2Go Session Broker should also suspend sessions before providing session data to X2Go Client if a candidate session is still/already running.

Providing Auto-Login via SSH Keys

The broker can also provide an SSH key to X2Go Client (the key in the below example has been obfuscated):

sub selectSession
{
  my ($user, $sid)=@_;
  if($sid eq "123456789")
  {
      print "SERVER:phoca:22\n";
      print "-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
yX7XLwCszCLM1FCYpdIGmM98vuHVcpNlVUBVgNcTxE1XCCnPZPjUXiNnUZPk1lme
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
o1q7Q1YmH43qI18lifjUhGZUTYWKQSsj2Am9bnjqaveV2aMEWymC8J9aJOYLpVZG
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
G1DwWnSRgyJaxRm4Ik0/kh78ioUfkVerXaCf2OKCMyiZBWcsNfvQwDa9MBrZ4rYW
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VR60OGB7dHy+7ozqkjzuX+uB04GIqPJwG797i26Bo4v7uhbALjMa5qsObqXIPM1S
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXX==
-----END DSA PRIVATE KEY-----";
 }
}

Providing SSH keys for X2Go Server sessions can be another mechanism of increasing usability (i.e. reducing the two authentication steps to one, see above).

It is highly recommended to transfer SSH keys only over encrypted channels (HTTPS or SSH broker).

It is also recommended to only transfer a temporary key, which gets removed from the X2Go Server immediately after successful authentication against the X2Go server.

wiki/advanced/x2gobroker/howitworks.txt · Last modified: 2013/03/28 10:46 by sunweaver