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:
1. broker client connects (like it does now)
2. broker client sends user+password via a post request and a unique
broker session ID string
3. broker accepts the connection (if creds are ok) and remember the
client-side generated broker session ID string
4. broker processes the given task (normally, the first task is
"listsessions", but it could be any task).
5. it returns some output (plain/text). In this output we have to
add a standardized extra line/field for the nextauthid: <uuidX>
6. the client will pick up this nextauthid value
7. NOTE older clients need to be able to ignore this nextauthid:
field.
8. the next client connect will be user+nextauthid (rather then again
user+password) plus again the broker session ID string
9. the broker will keep a record of broker session IDs and thus will
know what client instance connects when
10. 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.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpRuwqdlYoXe.pgp
Description: Digitale PGP-Signatur
_______________________________________________ X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
