You are here: Foswiki>Development Web>UserAuthMapping2dot0 (21 Aug 2017, GeorgeClark)Edit Attach

User Authentication and Mapping 2.0

The intention of this document is to collect and analyze the requirements for a next generation User Authentication and Mapping system. It will hopefully adapt into a FeatureProposal for the next major version of Foswiki. (3.0)

Definitions
Requirements
Other references
- Registration / Spam related:
Migration considerations

Definitions

Identity: a 1:1 mapping of some kind of token to a user. Once a relationship between a token and a user is established, it never changes. Every user has an identity and every identity represents a user (sometimes a virtual user, e.g. a generic guest user).
Authentication: proof presented by a user that they have a specific identity.
Authorization: permission for a user to perform an action, granted by the system.
External identity: an identity tied to an external system/user database, e.g. Google, Facebook, OpenID, corporate LDAP.
Identity provider: a system trusted to authenticate a set of external identities.
FUID: an identity within a Foswiki instance (Foswiki UID).
Persona: an identity visible to other users in the system, at least part of which is a human-readable representation (e.g. real name, nickname). There is a 1:1 mapping between persona and FUID, but FUIDs without persona may be allowed, depending on configuration. It may be permissible for personas to change, depending on configuration.

Requirements

Registration is not required.
- All features available to non-registered users
- Including updates, anonymous updates, search engines, etc.
Provide an FUID that never changes, for the lifetime of the identified person.
- There is no fixed format for an FUID but it should be storage-friendly.
- It may be desirable to have FUIDs that are human-readable, too (e.g. easily associated with an external user account).
  - Stable across marriages / divorces, etc.
- Stable across changes in employment
- Stable across technology changes. (passwords, biometrics, etc)
- Established on "first contact" from an external authentication.
- Once FUID is established, future authenticators can be added / disabled.
- Should we allow remove of an authenticator, which would permit reuse, or registration as a new FUID?
  - It should, at the very least, be configurable. Especially in corporate settings, it may be important to consider the FUID and the authenticator as effectively identical, to always link the FUID to the same user object in a user directory (LDAP).
- Conflict: Can 2 FUID's be merged? Same "person" visits while authenticated from two different authenticators.
  - This becomes really tricky once there are references to both FUIDs in e.g. topic metadata.
Provide a mapping from FUID to a wiki persona / cloak
- Generally referred to as the WikiName.
- Optional! Not all users will have a WikiName
- WikiWord (Camel Case) is not required - accommodates language differences: Ex: dePrima, von der Plum
- Permits punctuation. Ex: O'Donnel, O'Riley,
- N:1 A single WikiName can have multiple Authenticators, but a single Authenticator must map to only one WikiName
- Present email based registration system permits N:N between WikiName and email address. But it can be disabled
Permit a FUID to be connected to 1 or more external authenticators
- First contact with an authenticator establishes the FUID
- Subsequent Authenticators can be "joined" to a FUID
- User can securely add / remove "Authenticators"
- Examples: LDAP:<account>, Twitter:<account> OAuth:<account> ...
Usability:
- If a mapping to a wiki persona is available, display that persona when a FUID is encountered:
  - ACLs
  - Group memberships
  - Topic History
  - Topic REVINFO
- Users should work with wiki persona when practical:
  - Enter the persona into ACLs, ... (API to set ACLs, stored as FUID internally?)
- Backend should be scalable from the simple site with a handful of users, to an enterprise with 100's of thousands of users.
Auditing / Security
- Need to easily identify all activity by authenticator. (All changes made by Twitter:<account>)
  - Required as an admin tool. Preferably web based. At minimum server shell based. Hosted sites without shell access.
  - Nice to have as a end-user query. What did all my identities do.
- Should easily show the user: Last logged in from Authenticator;<account>
- Need to be able to delete users:
  - Remove WikiName mapping.
  - Remove from all ACLs (performance?)
  - Remove from all Groups
  - FUID must be preserved (keep history intact)
  - Spam cleanup may conflict with this
  - Authenticators need mechanism to inhibit all future access / ban future registration. (Spamming user)
- A site should be able to optionally specify "real name" mapping. Is that even possible?
- Optional: Block duplicate logins of same FUID, or de0auth other logins upon duplicate login. (YouShallHaveNoOtherLoginsBeforeMePlugin)
Search Engine and other special client support
- Accommodate "special" identities such as corporate indexing appliance. (May be IP based? or other token TBD?) (IpToUserMappingPlugin)
- Preserve "sessionless" guest access. (Expeimental feature in Foswiki 2.0)
- Accommodate "github" style authenticated access (Signed POST messages using a shared secret key) (FoswikiOrgPlugin)
Technology limitations
- RCS Store "author" fields must be ASCII Alpha-numeric, first character must not be numeric. (RCSWrap, for RCS version 5.7 and older. Version 5.9.3 lifts this limitation, accepting "Any visible graphic except $,:;@" Utf-8 characters are rejected.)
- JulianLevens feels the need challenge this limitation: aren't we moving away from RCS. Sorry getting close to implementation here, but is it an option to enhance RcsLite to allow a numeric char as the 1st char and remove this limitation?

Other related
- Extensible storage of user attributes:
  - Date/Timestamps first registered, etc.
  - Password expires / change required
  - Account enabled/disabled
  - Mobile number / carrier
- Cloaking of user attributes - Some attributes should be visible only to the admin, or user themselves.
- Extensible mapping of user attributes %USERINFO{ format="$mobile, $phone, $foobar ..."}%