Currently, ACCOUNT implements a single, monolithic security domain. We
would like to extend it to support multiple security domains, plus allow
a serial number to be associated with a particular account and allow a
user to be logged out of an account. This entails two protocol changes.
* ACCOUNT command
Currently, a user is logged in via "<prefix> AC <numeric> <account>". We
would change the syntax to "<prefix> AC <numeric> [+|-]<account>[,...]".
The '+' is optional and specifies addition of an account login. The '-'
would indicate log out. Also, "<account>" would become
"<user>[:<serial>][@<domain>]" instead of just "<user>".
* User mode +r
The argument to the +r user mode in NICK lines is presently a single
"<account>"; we would change this to "<account>[,...]", where "<account>"
is as described above.
Note that the changes are backwards-compatible with existing usage. Now
here's an explanation of what some of the terms I'm using mean:
* Serial number ("<serial>")
A service would have the option of associating a serial number with a
user account. This serial number could be incremented each time the user
changes his or her password (for instance). Then, the service can choose
to un-login a user presented with a lower-numbered serial number. This
could be used when an X username gets hacked, and the user changes his
password--the serial number would be incremented, and the hacker would be
automatically logged out, with no idea what the new password is.
* Security domain ("<domain>")
When a user logs in to X, he shouldn't necessarily be logged into Uworld
with the same username. The concept of a security domain allows us to do
this--X is in one security domain, and Uworld is in another, presumably
much more secure, security domain. Then a user can log into Uworld, get
logged in to an account and have all the benefits of the AC system--but
doesn't necessarily get logged into X. Similarly, a user can log into X,
and won't necessarily get logged into Uworld.
How to implement:
First of all, instead of a short char array in struct User, we'd have to
go to a linked list. (I don't anticipate many security domains on the
network, so a linked list will provide enough performance.) I recommend
keeping the char array in struct User for the empty security domain.
Everywhere we currently report the username to mortal users, we use the
empty security domain string. For opers, we may list all the details for
all the security domains in /whois. The +r channel mode should only be
predicated on whether the user has any ACCOUNT settings, but we may wish
to add a +R channel mode which takes a security domain argument--this
would allow us to create channels restricted to members of particular
security domains.
In the code, I'd recommend a function whose job is to parse the comma-
separated account strings and make the appropriate modifications to the
user--adding accounts, removing accounts, etc.--and another function
that builds the current account string for sending during the BURST.
These changes don't entail much work on the ircd side; most of the work
will be on the services side, since it's the services that would use
this information.
Examples:
* Log numeric nick 'AAAAA' into account 'Kev', 'Kev:1@uworld', and log
him out of 'zardox@nowhere'. (If no serial number is specified, then
the login is unconditionally removed. If a serial number is specified,
then only log the user out if the serial numbers match.)
- ZZ AC AAAAA Kev,Kev:1@uworld,-zardox@nowhere
* Update the serial number of 'AAAAA's 'Kev@uworld' login to 5:
- ZZ AC AAAAA Kev:5@uworld
(If AAAAA already has serial number 5, or a higher serial number, this
would be treated as an error.)
Thoughts? Anyone wanna write up this proposal in a clearer fashion?
Anyone wanna implement it? ;)
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
