UserCredentials.mesa
last edited by Levin on October 21, 1982 4:40 pm
DIRECTORY
Rope: TYPE USING [ROPE],
UserCredentialsUnsafe: TYPE USING [defaultOptions, LoginOptions, State];
UserCredentials: CEDAR DEFINITIONS =
BEGIN
This interface manages the credentials (Grapevine RName and password) of the human sitting at the terminal. It provides facilities for authentication of the individual and protection of the contents of the local disk against unauthorized access.
The individual must supply his credentials once per power-on of his machine. The credentials are retained by the system across world-swaps, rollbacks, and boots. The credentials are discarded only under the following circumstances: (1) the user leaves the Pilot world entirely (e.g., by returning to the Alto world), (2) the machine is powered off, (3) the user deliberately instructs the system to forget his credentials (e.g., by pressing the Idle button). These events delimit sessions, at least from the standpoint of credentials lifetime. Once the credentials have been discarded, the system will normally require that they be supplied and authenticated before any access to the disk is permitted.
State: TYPE = UserCredentialsUnsafe.State; -- {noCredentials, name, nameHint, nameAndPassword}
The credentials are stored on disk in a private location accessible only through this interface. The information stored there may be in one of the forms indicated by "State". "noCredentials" means that the disk area has never been initialized or that it holds credentials in an obsolete format from a previous, incompatible Cedar release. "name" means that the user's name is stored on the disk and that Login (see below) will accept only the named individual. Furthermore, the password supplied at Login time must be acceptable to Grapevine. (If Grapevine is unavailable, the password must match the last password for this individual that Grapevine acknowledged as correct.) "nameHint" means that any individual registered with Grapevine may successfully log in, but the system retains the credentials of the individual who did so most recently on this machine. "nameAndPassword" is functionally similar to "name" except that both name and password are stored on the disk in unencrypted form and that Login will prompt for credentials only if Grapevine rejects the ones stored on disk.
GetCredentialsState: PROC RETURNS [State];
This procedure returns the present form of the credentials stored on the disk.
ChangeCredentialsState: PROC [new: State] RETURNS [old: State];
This procedure permits the form of the credentials stored on the disk to be changed. If "new" is other than State[noCredentials], the name and/or password stored on the disk will be obtained from GetUserCredentials (see below), which may not produce the same values as are on the disk at the time ChangeCredentialsState is called.
LoginOptions: TYPE = UserCredentialsUnsafe.LoginOptions;
defaultOptions: LoginOptions = UserCredentialsUnsafe.defaultOptions;
Login: PROC [options: LoginOptions ← defaultOptions];
The detailed behavior of this procedure depends on the present state of the private disk area used to store credentials (see description of "State", above). Login is prepared to find the credentials area in any of the four states. If the initial state is "noCredentials", Login will prompt for a Grapevine RName and password, which it then presents to Grapevine for authentication. (Prompting occurs using the special initialization screen.) Once a valid set of credentials is supplied, Login asks if the desired final state is "name" or "nameHint" and rewrites the credentials area accordingly. (See the description of LoginOptions for an exception to this behavior.) If the initial state is "nameHint", Login prompts as for "noCredentials", then rewrites the credentials area in State[nameHint] using the name and password supplied. If the initial state is "name", Login prompts for the password only, obtaining the user name from the disk. This combination of name and password must be acceptable to Grapevine. Finally, if the initial state is "nameAndPassword", Login obtains both name and password from the disk and presents them to Grapevine. If they are rejected as invalid, Login acts as though the initial state were "name". At the completion of Login, the successfully authenticated credentials are passed to SetUserCredentials (see below).
Note: if, when Login is invoked, Rope.Length[GetUserCredentials[].name] = 0, it behaves exactly as just described. If, however, it finds Rope.Length[GetUserCredentials[].name] > 0, Login bypasses all of the above processing and returns without inspecting the disk credentials area. Thus, once credentials have been established using SetUserCredentials, they remain in effect until discarded by one of the circumstances described earlier. It is intended that the initial call of SetUserCredentials occur implicitly as a result of a successful Login, and that the credentials thus established remain in effect until explicitly changed by a call of SetUserCredentials or until explicitly discarded. If every Pilot-based environment sharing the disk on this machine calls Login before it permits the user access to any information stored on the disk, a strong guarantee of disk privacy can be made (assuming State[name]).
GetUserCredentials: PROC RETURNS [name, password: Rope.ROPE];
This procedure returns the current values of the user name and password. If Login has not yet succeeded, both name and password will be NIL. The same values will be returned in all Pilot environments on this machine, independent of boot, rollback, or world-swap. These credentials will remain in effect until the next call of SetUserCredentials.
SetUserCredentials: PROC [name, password: Rope.ROPE];
This procedure changes the values of the user name and password. No attempt is made to validate these credentials with Grapevine. Subsequent invocations of GetUserCredentials will return these values, even after a boot, rollback, or world-swap. These credentials will remain in effect until the next call of SetUserCredentials.
END.