ieb/sparsemapcontent — Issue #129: Make Authorizables support alternative IDs
Author: ieb
Created: 2011-11-23 00:26:10+00:00
State: open

At present authorizables support just a single ID, the internal ID. We need to be able to provide a mechanism where the user is able to identify themselves to the system using an alternative ID allowing the internal ID to be system generated.

I dont have a complete set of use cases for this at present, some are driven by FERPA requirements and simular legal frameworks in other territories. Some are driven by usability requirements. Here are some

For the sake of these use cases:
* The external id is ib236
* THe internal ID is 23423423
* The public id is drian

A user should be able to authenticate using an external ID that is never revealed to anyone other than the user.
* ib236 should never appear in any object other than the authorizable, and it should only be visible to the user who is that authorizable

Where an authorizable has been assigned a system generated ID, it must be possible for the user to associate a friendly ID with that authorizable, and it must be possible for that friendly ID to resolve to the authorizable when required.
* 23423423 and drian will resolve to the same Authorizable with ID 23423423

Where a public alias has been assigned, this must not be used for references
* drian must not be used to point to the Authorizable in other content items

Where a public alias has been assigned, this must be used for user facing data
* The Home url should be /~drian, but /~12312312 must also work

# Implementation.
## Private ID
* This should be stored in a protected field "_eid", only visible to the user.
* It should be used for locating the user object during authentication only.
* The _eid is private controlled by the code base and cannot be made public by ACL
* Administrative users have access to the _eid field.

# Public Alias
* All find by ID methods should also work with a public alias, so that if the no authorizable is found with the ID provided, the id is assumed to be the public alias and a search is performed. The system should cache the mapping between public alias and ID at an appropriate level.
* The public alias is public, ie it comes under normal ACLs for the authorizable.