Hi Josh,
On Fr 28 Feb 2014 04:23:44 CET, Josh Lukens wrote:
I've been working on a x2go setup using a session broker. The issue
I'm having is our auth uses 2-factor with tokens which I wrote a
working auth_mech for. The problem is the client resends the
initial username and password with each request to the session
broker which in turn tries to re-authenticate with them. Our system
doesn't allow reuse of token codes so all requests after the first
fail.I've taken a look at the beginnings of the dynamic cookie code in
the session broker to see if I could make it work for our needs. As
I understand the code that's there, the client would first connect
with the static cookie value then a new random uuid4 is created for
that user. That new random cookie would then need to be sent to the
client so it can use it for its next auth, but I can't find any
intent on how it should be communicated toward the client. From
then on each request gets a new uuid5 created cookie based on the
prior uuid and username, these could theoretically be generated
independently on both client and server (assuming client knows the
initial random one to see with).I'm happy to work on finishing this feature up but would like to
make sure I'm roughly inline with where you guys where going with
the feature so I have a few questions.How were you planning on communicating the randomly generated cookie
back to the client?Were you intending to send the new next cookie to the client on
every request or only do it once and have client and server keep
generating independently? (the later could be an issue for QT
client as QT4.8 doesn't support creating v5 UUIDs)How were you planning on handling multiple simultaneous connections
from one user? (looks like next cookies would clash with each other
in map)
Thanks for stumbling over the dynamics cookie stuff. Thanks for
offering your development help. I will happily accept it (speaking for
the broker part) and I am sure that Alex (X2Go Client's main
developer) is happy to include a new feature that allows broker auth
against a OTP-like/tf-auth backend.
The basic idea for the dynamic auth handshake is:
- broker client connects (like it does now)
- broker client sends user+password via a post request and a unique broker session ID string
- broker accepts the connection (if creds are ok) and remember the client-side generated broker session ID string
- broker processes the given task (normally, the first task is "listsessions", but it could be any task).
- it returns some output (plain/text). In this output we have to add a standardized extra line/field for the nextauthid: <uuidX>
- the client will pick up this nextauthid value
- NOTE older clients need to be able to ignore this nextauthid: field.
- the next client connect will be user+nextauthid (rather then again user+password) plus again the broker session ID string
- the broker will keep a record of broker session IDs and thus will know what client instance connects when
- and so on and so on and so on...
The only interesting part then will be: when will the session broker
forget old broker session IDs??? After 24h? After 7d? Also: will
broker session IDs be stored in RAM? Unhashed or hashed? Or on file
system?
Request for comments...
Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...