create new tag
, view all tags

Default registration in Dakar is different than Cairo

Cairo's default registration was to rely on external authentication (LDAP, NIS etc), e.g. the default TWikiRegistration did not ask for password. The docs explained how to configure TWiki for a public site; a TWikiRegistrationPub was supplied that asked for password.

Dakar switched that around, the registration asks for password and the password is handled by .htaccess by default. This is not in line with the TWiki:Codev.TWikiMission.

May be I miss something but what was the reason to switch the default?

-- TWiki:Main.PeterThoeny

The switch was to ensure that TWiki installs are secured by default. There seems to be a standard in open source, where server installs should be secure first, and then admins can choose to open them up. I'd prefer even more stringent defaults, like access from localhost only until TWikiAdminGroup is set to a newly created user, but its too late to add more things, especially when they've not been speced.

-- TWiki:Main.SvenDowideit

Peter: There are a few issues I must take very strong umbrage with.

First: You are using the trem 'authentication' in a context where 'authorization' applies.
Users are authenticated when they login. "Are you who you say you claim to be". This verification of identity may be done by using any one or more of a number of mechanisms, from the stand-alone password, use of tokens or biomentric, challenge/response, or some mechanism transparent to the user such as LDAP or NIS or Kerberos.

When a user registers to use a site the process is one of identification and authorization. "Who are you" and "Will your demand to use this system be permitted".

Many programmers and sysadmin overlook this latter point since they are in situations where everyone who applies will be permiited. An intranet is a good example of this. So is any Internet site that allows anyone at all to register. Twiki.org is another example of this. Conrrast this with sites that supply remote access for employees. Only the employees are going to be allowed to register. Note I say register. They have to register first.

Sorry if I seem pedantic about this but the distinction must be drawn otherwise incorrect thoughts and conclusions will follow. The security community has a clear understaning of the difference in these terms. Abuse of them just leads to confusion.

Second: Your assumption is highly based towards intranet users. I realise your experience is in that area. Mine is different. I suspect that your view of "TWiki for intranet, Mediawiki for <Internet" that you have voiced else (and which I and many thousand of others, as demosntrated by a search on Gogle demonstrates) disagree with.

The plugin authentication model - use of the $TWiki::cfg{LoginManager} - addresses "what you missed". No doubt future developers will add plugins for challenge/response. token cards, biomentrics, authorizing against a Samba server and so forth.

As for the Registration/RegistrationPub issue, I fully expect to have to edit the form to suit my site and/or client needs. You can see an example of this at http://www.infosecwiki.com/bin/view/TWiki/TWikiRegistration. I always considered the Registration/registrationPub matter to be an irrelevancy. Delete one and edit to other to your needs.

If you look at the source for TWikiRegistration.txt in Dakar you will the %IF{} construct is used - partly to address your point about use on the intranet where there will be local addresses as opposed to WikiNames. The %IF{} could also soak up the password field if necessary.

TWiki is most certainly NOT for use just on intranet!

-- TWiki:Main.AntonAylward

Anton, you blew my mind; I thought I knew what authentication was, and AFAICT Peter's use is what i would have expected.

Peter, not sure how it is out of line with the mission; depends on how you read the mission. In my experience, I am not aware of any intranet sites that operate without authentication by password. It's pretty much a standard; registering without a password sounds like a recipe for disaster. If you use an external login provider, you also have to check that the registering individual is actually who they say they are.

As Anton points out, TWikiRegistrationPub is now redundant, as its functionality is fully covered by TWikiRegistration. By the time I got to them, which was after Martin's changes for verified registration, the Password field existed in both versions. So Martin needs to answer your question.

-- TWiki:Main.CrawfordCurrie

There is some confusion. Let me try to explain using Anton's termonology.

By default, Cairo let the "are you who you say you claim to be" part handle externally (LDAP, NIS, Active Directory etc), not internally (with a .htpasswd file). Hence, the default registration form did not ask for a password. TWiki maps between login name (jsmith) to WikiName (JohnSmith). The advantage of this setup is that users do not need to remember multiple passwords and that TWiki admins do not need to worry about password changes since it is handled by the IT department.

The TWikiRegistrationPub was supplied in Cairo for sites that wanted to handle "are you who you say you claim to be" internally in TWiki. This is easier to setup but less flexible for users and admins.

By default, Dakar switched "are you who you say you claim to be" handling from external to internal. Hence, the need to register with a password for later login. Most admins will stick with the default setup, wich is easier to do (e.g. no need to get auth_ldap to work). However, this is at the cost of a less flexible setup for users and admins.

The "will your demand to edit/view this system/web/topic be permitted" is handled by TWiki's access control. This is the same for Cairo and Dakar.

If I understand correctly, I am talking about authentication, not authorization.

  • No. The process of logging in for an activity session involves authentication. This is the password, challenge/response, LDAP/NIS/AD, biomentric. It doens't matter if the ID is presented via a form (login screen) or an environment variable (REMOTE_USER).
    The process of registration, allowing access, determining what access will be permitted for that identity, is termed Authorization.
    Very simply: you must first be authorized before you can authenticate.
    Perhaps the LoginManager would have been better termed the AuthenticationManager. Its modular role make the distiction between authentication and authorization clear. It is not used to register new users.
  • These are the accepted uses security community.
    I can see that you might become confused because in your intranet settings the authroization has already been done - otherwise the user wouldn't be able to have logged onto the intranet in the first place.
    -- AJA
  • Nevertheless authorization to use TWiki's resources (as opposed to authorization to use the intranet) is done by TWiki, if only by mapping login users to the wikiname namespace. The difference between "traditional" services and (T)Wiki is that in wikis normally allow their users to do their own authorization by just registering. This holds true not only in the intranet, but for many _inter_net wikis as well, e.g. TWiki.org. -- haj
  • The step/action of authorizing exists, even if the flow of control is seamless and does not require manual or external intevention. Failing to recognise that it does occur, even if there is no explicit gate or hurdle invovled as is the case with Twiki.org or your intranet based registration-on-demand (which in reality is just taking a delegated authorization done by someone else that lets the user be on the corporate intranet in the first place). -- AJA

And yes, TWiki is used outside of the TWiki Mission's target audience, which is great. Especially good if there are many public sites (for publicity and Google ranking). It is difficult to assess the ratio of TWiki's taget audience vs others. A good proxy is the TWiki:Main.TWikiInstallation directory (it currently lists Academic: 66, Corporate: 174, Government: 17, Individual: 67, Non-profit: 65, Other: 11)

  • Peter: you are basing your numbers on those who have registered. I turn to Google and Yahoo and other search engines for TWiki/WebHome and Main/WebHome and see many hundreds of sites out there 'in the wild'. -- AJA
    • I was refering to the ratio, not the absolute number. Only a small fraction of site admins list their installation in the directory. -- PeterThoeny - 11 Oct 2005
      • Peter, that is a specious argument. You don't kow the real numbers. As you say 'only a small fraction of site admins list their installation in the directory'. That applies to both internal and external uses. You have no reason to think that the ratio in the directory is the same as the ratio in the real world. -- AJA
      • It is only a proxy, the ratio might be somewhat different. I suspect that corporate sites are underrepresented since corporate policy prevents some admins from listing their installation. My TWiki related e-mail correspondence is largely with corporations. But I think we agree that it is healthy to have a balance in deployments. -- PTh

-- TWiki:Main.PeterThoeny

I refactored this discussion from Bugs:Item594.

As for Authentication and Authorization, AFAIK Cairo relied on .htaccess to specify the authentication mechanism (the sample was for BASIC authentication using a .htpasswd file and LDAP authentication). Dakar extended that model to provided different "LoginHandlers" as Anton highlighted. Currently you can use the "TemplateManager" (the easiest to setup, IMHO), the HttpasswdManager (that uses the old behavior) or just set it to "none" and let the .htaccess file to it's job. So, if I'm not mistaken, if you want to reproduce the Cairo behavior the LoginManager should be set to "none" and the Session Management turned "off".

Finally, please when you say that something is against the TWiki:Codev.TWikiMission, could you provide a reference off what part of the mission is being violated?. That way your point could be better understood. (Just for the records, I agree that if there were no way to reproduce the Cairo behavior with Dakar with respect of LDAP or anything achievable using .htaccess, that would be against the TWiki:Codev.TWikiMission " Protect corporate investment").

-- TWiki:Main.RafaelAlvarez - 10 Oct 2005

In this particular case, I was referring to the very first phrase of the TWikiMission, "TWiki is a leading-edge, web-based collaboration platform targeting the corporate intranet world." In this setting, TWiki authentication should be done via the existing directory (NIS, LDAP etc). It also applies to "easy maintenance" (no password maintenance by TWiki admin) and "give broad corporate appeal" (users do not need to remember multiple passwords)

  • There's something short sighted going on here, Peter. At the moment I am setting up an Internet based TWiki site that sits in a corporate DMZ and does its authentication to a LDAP server behind the local firewall. As it happens, that LDAP server is replciated form a LDAP server at another site -- across the Internet. The local verification is for performance, it could equally well have done the verification across the Internet.
    limiting yourself to intranet use is telling many corporations that you don't think TWiki is robust. That in turn will limit its acceptance.
    -- AJA
-- PeterThoeny - 10 Oct 2005

are you asking us Internet people to fork?

-- SvenDowideit - 10 Oct 2005

No, as you might recall, I was never supportive of a fork. And we have seen in the past that it only hurts the TWiki project. However, I am supportive of a TWikiDistribution model with one core and several distributions for different vertical markets.

-- PeterThoeny - 10 Oct 2005

Back to the subject, what actions should be taken?

  1. No action - leave as is
  2. No change in registration page, but update docs to specfically recommend and explain external auth setup if on intranet
  3. Change default setting back to typical intranet installation

I am genuinly asking to find closure on this.

-- PeterThoeny - 10 Oct 2005

Peter: If you are seriously trying to find closure then you will have to back of from what seems to be an obsession with your intranet-only view and admit that your statements like "most admins will ..." are merely you voicing your own experience whcih is focused on the intranet deployment of TWiki, something that is not shared by others. Many others, as a search using Google will testify.

You will also have to back of and take the established terminology form the security world that the seting up of an acocunt and granting the rights that go with it is is "authorization" and logging in is a matter of "authentication". Your intranet scheme already has the users authorized - as you point out the information is in a LDAP/NIS/AD respoitory - so I can see where you confusion comes from. It is probably exacerbated by your policy of no discrimination/discernment when people register for the tiki.org site, so you enver have to see the detailed process of selective or differential authorization. (Mind you, I can see that apply to intranet wikis as well.)

The intranet installation is only "typical" for you. I have never yet and do not forsee ever doing an intranet installation of TWiki. For me the Internet instalaltions are the norm.

If you wish to propose a set of alternatives then it should be something like this:

  1. Document in detail what it takes to set up Dakar for both intranet and Internet use
  2. Extend the already exisiting plugable login mechanism to deal with "plugable registration"
  3. Fork

But you are going to have to start by backing of from your obsession with the idea that Twiki should be used predominantly on the intranet.

I would like to see TWiki be more popular than MediaWiki/WikiPedia. I'm sure you would be gratified too if it was. But to me, your attitude of "TWiki for the intranet; WikiMedia for the Internet" rings of defeatism, or perhaps parochialism.

  • First time my attitude is branded as parochial. I did not know the word and looked it up on the dictionary. Every day I can learn something new. Thanks for sharing. -- PeterThoeny - 11 Oct 2005

-- AntonAylward - 10 Oct 2005

Peter, thanks for the clarification. I thought that you were refering to the "protecting asset" line.

Given that we're talking about corporations and intranets, I would like to tell our story:

We at Consis use TWiki for our Acsele development intranet. Our HQ is located in Weston and our development center is in Venezuela (where we're hosting the intranet). We don't have a worldwide LDAP server or a VPN, and the intranet must be seen by the higher ups in Weston, so we relied on the .htaccess and .htpasswd mechanism since day one. And the first version I installed was TWikiBetaRelease2004x01x19.

OTOH, IIRC, Cairo didn't ask you for passwords, nor recognized you as the proper user, unless the scrips in bin where marked as require valid-user (using the .htaccess file), in that case the .htpasswd mechanism was used by default, unless the "LDAP" or the "DIGEST" lines where uncommented from the sample file. Dakar default is not different from that default.

So, for a closure of this, I propose that the default for Dakar be the same as the default for Cairo (that is, leave LoginManager as none, no session management, with sample .htaccess to use Apache for authentication)

-- RafaelAlvarez - 11 Oct 2005

See also:

for Internet based authentication methods that could be used to extend the plugable authentication suite.

-- AntonAylward - 11 Oct 2005

I'm sure the code supports both password used and password less configurations, it seems back in Dec 2004 I checked in a version that asked for password in both cases. If so, my bad.

In terms of defaults, its a moot point: of course different people want different PlatformDefaults, TWiki caters to different audiences but we are forcing everyone to choose either the one set menu or customise from it. As the Apache/Linux bods have 90% of the market everyone else has to hand order.

As the change control board will likely vote that it is late to arrange TWiki to load a different file containing PlatformDefaults, and now factoring in Internet/Intranet use (i.e. replaces LocalSite.cfg.txt with a choice of defaults/Debian.Apache.Unix.Intranet.cfg, defaults/MacOsX.Apache.MacOs.Internet.cfg), I can only suggest we ask the one contentious authentication question ("intranet vs. internet") explicitly for Dakar and aim at PlatformDefaults for Edinburgh.

Other ideas welcome, of course.

-- MartinCleaver - 11 Oct 2005

I'd still go for putting some (more) intelligence into the forms, similar to what has already been done with %IF{"$ ALLOWLOGINNAME"... in TwikiRegistration.txt. If we pass the config settings of PasswordManager (and, btw, NeedVerification) in the %constantTags hash, then we could avoid expanding the <tr> elements asking for the password. After all, if you have LDAP, NIS, whatever, you really set your PasswordManager to 'none' with configure.

FWIW, I'm currently running with the following diffs:

  • In TWiki.pm, add some more config values as tags
--- ../_Dakar/lib/TWiki.pm      2005-09-30 12:31:12.000000000 +0200
+++ lib/TWiki.pm        2005-10-10 16:21:26.058622900 +0200
@@ -298,4 +298,6 @@
     $constantTags{ALLOWLOGINNAME}  = $TWiki::cfg{Register}{AllowLoginName};
+    $constantTags{PASSWORDMANAGER} = $TWiki::cfg{PasswordManager};
+    $constantTags{REGISTERNEEDVER} = $TWiki::cfg{Register}{NeedVerification};
     # locale setup

  • In TWikiRegistration and NewUserTemplate, react accordingly
    • Oh, I'd better not copypaste those as <verbatim but attach'em - 629-column-lines may be a bit hard to read...

-- HaraldJoerg - 11 Oct 2005

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff NewUserTemplate.diff r1 manage 0.5 K 2005-10-11 - 08:05 HaraldJoerg Don't restrict user home page if there's nothing to protect
Unknown file formatdiff TWikiRegistration.diff r1 manage 4.6 K 2005-10-11 - 08:04 HaraldJoerg Only ask for passwords if TWiki has a password manager
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2005-10-11 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.