Difference: TWikiUserAuthentication (26 vs. 27)

Revision 272013-06-28 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

Line: 8 to 8
 

Overview

Changed:
<
<		Authentication, or "login", is the process by which a user lets TWiki know who they are.
>
>		Authentication, or "loging in", is the process by which a user lets TWiki know who they are.
 
Changed:
<
<		Authentication isn't just to do with access control. TWiki uses authentication to identify users, so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of shadows.
>
>		Authentication isn't just about access control. TWiki uses authentication to identify users so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of ghosts.
 
Changed:
<
<		TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access, or only for changes. Authentication is also essential for access control.
>
>		TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access or only for changes. Authentication is also essential for access control.
  Quick Authentication Test - Use the %USERINFO% variable to return your current identity:
Changed:
<
<		TWiki user authentication is split into four sections; password management, user mapping, user registration, and login management. Password management deals with how users personal data is stored. Registration deals with how new users are added to the wiki. Login management deals with how users log in.
>
>		TWiki user authentication is split into four categories: Password management, user mapping, user registration, and login management. Password management deals with how users' personal data is stored. Registration deals with how new users are added to the wiki. Login management deals with how users log in.
 
Changed:
<
<		Once a user is logged on, they can be remembered using a Client Session stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.
>
>		Once a user is logged in, they can be remembered using a Client Session stored in a cookie in the browser (or by other less elegant means if the user has cookies disabled). This avoids the need of having to log in again and again.
  TWiki user authentication is configured through the Security Settings pane in the configure interface.
Changed:
<
<		Please note FileAttachments are not protected by TWiki User Authentication.
>
>		Please note that FileAttachments are not protected by TWiki user authentication by default. The TWiki:TWiki.ApacheConfigGenerator has an option to protect file attachments.
  TIP Tip: TWiki:TWiki.TWikiUserAuthenticationSupplement on TWiki.org has supplemental documentation on user authentication.
Line: 37 to 37
 

User Mapping

Changed:
<
<		Often when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import to TWiki, such as user groups.
>
>		Often, when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import into TWiki, such as user groups.
 
Changed:
<
<		By default, TWiki supports mapping of usernames to wikinames, and supports TWiki groups internal to TWiki. If you want, you can plug in an alternate user mapping module to support import of groups etc.
>
>		By default, TWiki supports mapping of usernames to wikinames, and supports TWiki groups internal to TWiki. If you want, you can plug in an alternate user mapping module to support importing groups and other entities.
 

User Registration

Changed:
<
<		New user registration uses the password manager to set and change passwords and store email addresses. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).
>
>		New user registration uses the password manager to set and change passwords, and to store email addresses. It is also responsible for the new user verification process. The registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).
 
Changed:
<
<		The registration process is also responsible for creating user topics, and setting up the mapping information used by the User Mapping support.
>
>		The registration process is also responsible for creating user topics and setting up the mapping information used by the User Mapping support.
  ALERT! Note: If you are restricting the entire Main web to TWikiGuest, you are required to add TWikiRegistrationAgent to ALLOWWEBCHANGE in your Main/WebPreferences. By doing so, new users are able to register without any errors.

Login Management

Changed:
<
<		Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.
>
>		Login management controls how users log in. There are three basic options: No login, login via a TWiki login page, and login using webserver authentication support.
 

No Login (select none in configure)

Changed:
<
<		Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.
>
>		No Login does exactly what it says. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity so you can't track individual user activity.
  ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to administrators.
Line: 71 to 71
 
  1. Use the configure interface to
    1. select the TWiki::LoginManager::TemplateLogin login manager (on the Security Settings pane).
    2. select the appropriate password manager for your system, or provide your own.
Changed:
<
<
    1. HELP there is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent Browsers from remembering username and passwords if you are concerned about public terminal usage.
>
>
    1. HELP there is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent browsers from remembering usernames and passwords if you are concerned about public terminal usage.
 
  1. Register yourself in the TWikiRegistration topic.
    HELP Check that the password manager recognises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
  2. Create a new topic to check if authentication works.
Line: 91 to 91
  Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.
Changed:
<
<		The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules such as mod_auth_ldap or mod_auth_mysql you can just plug in directly to them.
>
>		The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules, such as mod_auth_ldap or mod_auth_mysql, you can just plug in directly to them.
  The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.
Line: 105 to 105
 You can use any other Apache authentication module that sets REMOTE_USER.
  1. Use configure to select the TWiki::LoginManager::ApacheLogin login manager.
  2. Use configure to set up TWiki to create the right kind of .htpasswd entries.
Changed:
<
<
  1. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
>
>
  1. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what needs to be done.
    HELP If you got it right, the browser should now ask for a login name and password when you click on Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
 
ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
  1. You can create a custom version of the TWikiRegistration form by copying the default topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user profile page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
    The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user profile page by creating the Main.NewUserTemplate topic, which will then override the default.
Line: 118 to 118
 

Logons via bin/logon

Changed:
<
<		Any time a user requests a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" link as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.
>
>		Any time a user requests a page that needs authentication, they will be forced to log on. It may be convenient to have a "login" link as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log in.
  The bin/logon script enables this. If you are using Apache Login, the bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. Once authenticated, it will redirect the user to the view URL for the page from which the logon script was linked.
Line: 127 to 127
  TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.
Changed:
<
<		You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don't enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
>
>		You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don't enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers, it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
  There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.
Line: 190 to 190
 

Controlling access to individual scripts

Changed:
<
<		You may want to add or remove scripts from the list of scripts that require authentication. The method for doing this is different for each of Template Login and Apache Login.
>
>		You may want to add or remove scripts from the list of scripts that require authentication. The method for doing this is different for Template Login and Apache Login.
 
  • For Template Login, update the {AuthScripts} list using configure
  • For Apache Login, add/remove the script from .htaccess

How to choose an authentication method

Changed:
<
<		One of the key features of TWiki is that it is possible to add HTML to topics. No authentication method is 100% secure on a website where end users can add HTML, as there is always a risk that a malicious user can add code to a topic that gathers user information, such as session IDs. The TWiki developers have been forced to make certain tradeoffs, in the pursuit of efficiency, that may be exploited by a hacker.
>
>		One of the key features of TWiki is that it is possible to add HTML to topics. No authentication method is 100% secure on a website where end users can add HTML, as there is always a risk that a malicious user can add code to a topic that gathers user information, such as session IDs. TWiki developers have been forced to make certain tradeoffs, in the pursuit of efficiency, that may be exploited by a hacker.
  This section discusses some of the known risks. You can be sure that any potential hackers have read this section as well!
Line: 214 to 214
  If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as "rather dodgy".
Changed:
<
<		Most TWiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the aether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.
>
>		Most TWiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the ether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.
  Of the two shipped login managers, Apache Login is probably the most useful. It lets you do this sort of thing: wget --http-user=RogerRabbit --http-password=i'mnottelling http://www.example.com/bin/save/Sandbox/StuffAUTOINC0?text=hohoho,%20this%20is%20interesting
View topic | History: r28 < r27 < r26 < r25 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
Note: Please contribute updates to this topic on TWiki.org at TWiki:TWiki.TWikiUserAuthentication.