This pages describes issues and design ideas for "transient" accounts. This notion is an attempt to find a middle ground between our two previous models:
- The LiNC model, which had restricted account creation. Accounts were centrally (and often manually) managed by us.
- The MOOsburg model, which had unrestricted account creation. Account management was left to the users.
For projects currently on the horizon (ROLE, Awareness, and possible bridge-based successors to MB for community uses), we will likely not want unrestricted account creation in the interest of reducing clutter and maintaining focus. In each case, however, there will be non-primary users:
- Activities created by ROLE teachers will in some instances need to be securely accessed by students. Awareness activities will definitely need such access.
- For community systems, we might want to manage a "primary" account for a given community organization, but organizations may also want accounts for individual members.
Issues include:
- Management overhead. What tools are needed to manage secondary accounts?
- Security. A primary account should have full priviledges of any secondary accounts associated with it, but the reverse should generally not be true.
- Namespace management. What happens when two primary users want to make secondary user accounts with id "smith"?
- Presentation. Information about the primary account should be available for presentation in the UI.
- "Home directory" support, for secondary user conferences (etc...).
The Accounts object
A proposed solutions is to add an "accounts" object that can be placed in a bridge directory:
- The interactive UI for this object would provide basic account administration tools: adding accounts, removing accounts, and changing passwords. It should also have an option for bulk-disabling all accounts.
- The accounts established in the object would only exist in the context of the directory where it was created. A user logged in under such an account would essentially have "guest" priviledges elsewhere in the system. (The existing permissions scheme which looks for a prefix of "guest" in user ids was designed to support this kind of solution.)
- Group management could be handled somewhat informally. The accounts object could maintain a notion of a "group" and provide utilities for updating the permissions of other objects in the directory based on group name. (Further group ownership info could be stored in EODescriptor properties.)
- The accounts object could "contain" conference directories for each secondary user.
Changes required to implement this mechanism include:
- Ability for the client to pass context information to the server on login. This is needed so that the server-side authenticator mechanism can look up appropriate Accounts objects to check passwords against.
- The existing authenticator scheme does not assume that passwords are strings, so we can simply pass an object ("
ContextPassword"?) that includes the user-supplied password string and requested path or other context information.
- A new authenticator implementation ("
ContextAuthenticator"?) can be added that will inspect incoming passwords. The authentication info will first be passed to a "real" authenticator (for primary accounts). If that fails, the context information (if available) will be used to look for one or more Accounts objects to authenticate against. This approach will prevent real accounts from being "locked out" by secondary accounts, but still allow accounts with the same id to be distinguished by password. It will also make authentication faster for real accounts -- only secondary accounts will pay a penalty for the extra lookups.
- A PasswordExtractor implementation could be used to construct
ContextPassword objects for web requests.
- Ability for the server to pass revised account information back to the client on successful login. This will likely require changes to the Authenticator interface to allow it to return a user id (or perhaps a User object?) in addition to a success/failure indication. This additional information will need to be handled by ServerImpl when constructing the User object that is sent back to the client. The revised account information would:
- be prefixed by "guest"
- include the id of the primary account holder
- end with the id of the secondary account
- include (in a separate field) the location or object id of the Accounts object with which the account is associated
- Users whose ids start with "guest" would need to be prevented from changing permissions under any circumstance, even on objects that they create.
Example: Consider "real" users smith and jones, where smith creates a secondary account within directory "project" that has user id jones. The full id of the secondary account is "guest-smith-jones" (refered to as "g-s-j" below). An object created by g-s-j in project could have explicit write permissions by g-s-j and smith. Permissions changes would be restricted to "smith" only. Such an object:
- Would be exempt from the "guest*" prefix check (since ownership is explicit). A check would likely need to be added in the permissions UI to disable the "anybody with an account" option for users whose id's start with "guest".
- Would not be accessible by the jones account, since the account names would not match.
- Would be accessible by the smith account (by permissions setting).
This approach:
- Requires no changes to the existing permissions implementation, beyond the restriction that guest copies of chat sessions are stored (this is implemented)
- Location of user profile information, such as avatar, full name, contact info, etc... (not currently implemented)
In the 020919 implementation, home directory support is basically hardcoded: The user's id is appended to "/users" and an EmbeddedObjectPath is constructed. This will need to be abstracted to better support transient users.
A proposed abstraction is a HomeFinder utility that hides configurable discovery of home directories. This utility would function as follows:
- At client startup, the login context (path) would be passed to the HomeFinder for later use
- When the first request for the home directory is received, the HomeFinder would:
- Look for a directory in a standard (but configurable) place like "/users". This step could be bypassed for guest accounts.
- See if a login context was provided. If not, print a warning
- Follow the same path traversal algorithm used by ContextAuthenticator, asking authenticator objects for a home directory for the user.
- If a value is found, cache it for future calls
This approach has the potentially significant disadvantage of requiring that the entire accounts object:
- be readable by any user defined in the object
- be transfered to the client on every login
An alternate approach would be to perform this search server-side, extending AuthenticationResult to include arbitrary information that would be passed back to the client. This has been implemented 020924.
Permissions interactions with secondary accounts
The current set of Permissions implementations used in Bridge base access on user name.
For cases where specific secondary accounts can be specified, the existing mechanisms should just work, e.g., "writable by guest.webpal.smith". This will work for web access, since each request is authenticated in the context of the user's accounts object. The possibility exists, however, that another user could create another secondary account in a different namespace with the same id. This account would then assume the priviledges of the other secondary account. Similar problems exist in cases where a group of accounts are being specified with a wildcard.
A possible solution is to embed information about the namespace in which the user is defined within the user id. Note that for prefix-based guest restrictions to work, the generated names would still have to begin with "guest". Options include:
- Use the path of the accounts object in the name, with slashes replaced by dots, e.g., "guest.users.projects.webpal.accounts". This approach:
- produces meaningful names
- but is long
- but will break accounts if the accounts object is moved or renamed
- but, since objects names are ultimately controllable by client-side entities, may still be subject to spoofing
- Use the ObjectID (or the timestamp portion thereof) in the account name, e.g., "guest.09485738573-edu.vt.cs.collab......smith"
- difficult/impossible to spoof
- survives moving or renaming
- but very long, unless class name truncated
- but not meaningful
The "meaningfulness" of a user id is primarily useful for debugging. In practice, nothing but the "assigned name" of a user is likely to ever show up in the UI, at least once we develop better tools for managing permissions. Given this, the ObjectID-based approach seems better. Initially we will truncate the ID in the interest of speed. We will also keep the owner/project name in the preliminary accounts object implementation, in case we decide that this needs to be used in the UI to distinguish otherwise identical accounts.
Group management
The initial implementation of the accounts object (September 2002) did not include a notion of groups. While informal group management is suitable for many cases, it may not be suitable for all. Two cases that arose immeidately were:
- In the BMS MOO activity, access to admin rooms needed to be restricted to hosts. This was done (sloppily) by giving read access to "...Mr*" and "...Dr*". This is not a viable long-term solution.
- In the AMS awareness project, group management via individual permissions was tedious, even though each group had a single folder. Some of the overhead could have been reduced with a more usable UI, but group determination for log parsing would still be a problem.
The latter case suggests part of a solution: encode group information within the user id. While this will not handle cases where the same user is in mulitple groups, it will handle the common case. Proposed enhancements include:
- Addition of a list of groups to the
LocalAccounts object. This will be used to generate UI elements and to save typing.
- Sub-groups could be supported via group names that include a "."
- Extension of per-user record to include an optional group identifier. This will be set from the group list defined in the accounts object.
- Modification of Authenticator to add group information to the user id on successful login
- Enhancement of the group list UI:
- Filters by group
- Flagging of users associated with groups that no longer exist
- Better explanation of "owners" list.
- Enhancements to the permissions UI:
- Flagging of objects that are not readable/writable/perm-able by owner accounts
- Support for setting perms by group/subgroup
- Since addition of group info will make the already-long secondary account names even longer, web and java representations of user lists will need to be shrunk.
- We might also consider (re-) adding a tag to the accounts object that can contain a human-readable identifier for the accounts in the accounts object. This could then be added to the user's SessionData and used in the UIs while the user was logged in. Leaving it out of the actual user id would make it less problematic to change.
- Will the name check in Permissions need to be updated to ignore group, at least for objects not owned by a group? E.g., something accessible by guest.999999.pli should be accessible by guest.999999.mygroup.pli?
User Interface(s)
Categories of UI work include:
- UI for manipulating a list of valid accounts, setting up "home" directories, etc...
- UI for managing permissions on a set of objects owned by secondary accounts
- UI changes to provide/suppress information about secondary accounts in places like user lists
|