The "local accounts" object (in edu.vt.cs.collab.bridge.security) was added in early '03 to support student accounts. It has proven basically functional, but has numerous flaws:
- Accounts cannot be managed from the web interface
- Users cannot change their passwords (even from the java gui)
- The object must be named "accounts", as there is no other way to specify which accounts object should be used if multiple are present
- The object requires that permissions settings include ugly entries like "guest.75638.SomeStudent"
- The configuration gui is clunky
- Chats and other transient objects created by (or on behalf of) guest users defined in a local accounts object are not retrievable, and in some cases will leak. (Incomplete support is present for setting a home directory for these accounts.)
- Bulk account creation is tedious, as account id, group, and password must be set in seperate steps
Usability issues aside, the basic idea of the local accounts object could be extended to support authentication against other sources, such as email or ldap servers. Issues include:
- Security issues, if passwords are transmitted across unencrypted connections
- Complexity issues a single accounts object authenticates against multiple services
- Support for multiple accounts objects would be a partial solution, though this would complicate permissions settings
- Support for an account aggregator object that would authenticate against multiple accounts objects, while presenting a single guest.NNNNNN prefix would be a possible work-around
- Specifying accounts and URLNames, e.g., "pop3://someuser@mail.domain.com/" might also work. This could override any global settings in the accounts object.
- POP and IMAP are likely to be straightforward, though LDAP may be more complex. Some type of runtime configuration of site-specific libraries (e.g., see Integration with VT directory services) may be needed.
Possible approaches:
- Allow user names to be specified as URLs, as described above
- Add an option to the current set of password options (unique/shared) for authentication against an external source:
- Protocol: POP3, IMAP, LDAP, others?
- Server name (could be blank to force accounts to be specified as name@server)
- Option for "specified users only" vs. "any user that can authenticate"
- Re-partition options:
- User names
- Specified user names only
- Any user name with appropriate authentication
- Passwords
- Specified passwords
- Shared passwords
- Authenticate against external server
- Default protocol [POP3], server, and (optional) port
|