Table of contents
Authentication methods. For standalaone sites (not connected to a central authentication server), you can use “Just Tiki” or “Web Server”. For sites that are part of a larger environment Tiki offers Apache (basic HTTP auth), LDAP based Pear::Auth, CAS, and Shibboleth authentication.
The installation environment plays a role in determining the authentication method to be used. On a fully accessible server, an administrator has a choice of any/all of the authentication methods listed on this page.
Tikiwiki 2.0. OpenID is an open and decentralized identity system, designed “not to crumble if one company turns evil or goes out of business”.
Selecting OpenID in Tiki 3.0 will ad an OpenID login module below the regular login module.
More information on OpenID
Tikiwiki is able to detect when a visitor to the site is currently logged in using Basic HTTP Authentication. If the username of the user matches a username within Tikiwiki’s database, Tikiwiki will automatically log the user in and, of course, grant all the assigned permissions.
Using Web Server authentication can be convenient for a shared hosting installation of TikiWiki. User management becomes more of a challenge if multiple Tiki’s are to be installed. One option for centralized user control of Web Server authentication is Locked Area Lite. However, in Tiki 3.0 group information and users will still need to be added to each and every sub-Tiki inside the authorized domain.
TikiWiki uses the Pear:Auth library which permits many types of external authentication.
In Tiki 3.0, Pear:Auth is primarily set up to work with LDAP. Previous versions of Tiki permitted IMAP/POP authentication.
- CACert (or other) Client Certificates
- GPG/PGP PKI, including tools such as WebPG (here and here)
- 2-Factor authentication, such as Google Authenticator or SMS
- Post-Login Security Question? Like when logging into a bank website.