Tags:
extract_idea1Add my vote for this tag create new tag
, view all tags
SvenDowideit is refactoring this topic to seperate the AddTWikiAdminUser feature from the SimplifiedUserMappingCodeInterface feature

use the configure password for a new TWikiAdmin account

Strongly related: SimplifiedUserMappingCodeInterface, RefactorUsersCode, AddTWikiAdminUser, MergeFuncUsersContribWithFunc, CaseInsensitiveUserMapping

The my work on the JoomlaUsersContrib and OpenIdUserContrib, discussions with MichaelDaum on LdapNgPlugin works, and watching TWikiIRC make it clear that TWiki needs a 'known safe' user. In the JoomlaUsersContrib, I re-used the TWikiAdminGroup setting in configure, and point that at the Joomla Administrators group, but this is not a satisfactoy solution for totally customisable user system.

Instead, realising that TWiki's configure script already has a password which is known to a TWiki installer / administrator, and is required as one of the initial seps in installing, I'm intending to add TWikiAmin to work similarly to the internal TWikiGuest user, add it as the default user in TWikiAdminGroup.

This resolves one of the major installation stage insecurity issues of a new TWiki - that the TWikiAdminGroup is shipped open.

Some work will need to be done to make it possible to authenticate as this user (in the non- TWikiUserMapping cases) to prevent TWiki from asking LDAP (for eg) who the TWikiAdmin user is.

Benefits

  • a more secure default install
  • new users often come to IRC and ask I've installed TWiki, configured it, and its running, whats the Admin passord?
  • we have an internal TWikiAdmin user for use on non-authenticated TWiki's, or on TWiki's that use non-TWikiUserMapping

Development Plan

Thus the DefaultUserMapper will be able to be used with the Login types - such as ApacheLogin or TemplateLogin, or be added to using TWikiTopicUserContrib, JoomlaUserContrib, OpenIDUserContib, LdapContrib etc...

TODOs that have come up

  • seperate user information URL from displayname - as Michael points out, if you have an external user management UI, the User's info should point there
    • this will require skin changes

  • the use of the rego_disabled flag and the rego_supported flag to show different topic texts
  • lock down distributed topics (like TWikiAdminGroup etc)
  • docco
  • review class and method structure for completeness

TODOs that are expected to be deffered

  • implement a mixin mapper, that can allow users or groups to be come from more than one mapper (such as mixing twiki topic groups into an LDAP system)
  • add newly registered users to a configurable Group - NoGroupUserProblem and many other user requests
  • working out a way in configure to let the user clearly select & mix from which mappers to get stuff
    • ie, to get users from ldapmapper only
    • but to get groups from ldap and twiki topics
    • and howto mix same groups together, or to over-ride
  • MixMasterMapper
  • some way to have optional settings in configure so that the htpassword selection is only turned on if the user selects a mapper that says it needs it
  • while moving the TWiki Topic User and Group mappings, to a contrib, I'm not even sure that the Main web is needed when an alternative mapping is used :/
  • need to add a twiki_topic_based_groups context / setting to enable/disable addnew groups UI
  • when the primary auth is broken (I still have not had time to see what can be done wrt external auth)
    • they can click on a SCRIPTURL{log[io]n}?sudo=sudo link, which takes them to a templatelogin based UI, and can auth as {TWikiAdminUser}

Progress report %NEW%

28-Apr-2007

  • added ASSERTs and ported a simplified (and non-caching) version of the JoomlauserMapper for testing
  • added UserMapperName to canonical_ids to ensure TWiki know's if a user_id in rcs etc is one of its
  • created a BaseUserMapper that has 3 users - admin, guest and unknown, and one group - admin, with user & group names from configure settings (some unit tests fail - working on fixing them)

30-Apr-2007

looks like TWiki::Users will be going away, with TWiki creating a mapper, that then contains the relavant password classes. many usermappers don't require plugable password engines, as they provide the full auth chain. whereas TWikUserMapper will continue to enable plugable password handlers.

3-May-2007

The existing Plugable password handlers have been pushed into the TWikiUserMapping, as many mappings will have their own, and unique to them method of authentication. BaseuserMapper now is able to authenticate cfg{AdminUserWikiName} using TemplateLogin and cfg{Password}

8-May-2007

  • moved most topics to TWikiUserMappingContrib, needs cleaning and docco
  • added TWiki::cfg{Register}{EnableNewUserRegistration} to configure - and set it to false on develop.twiki.org

10 May 2007

  • fix up twiki cgi-script to do login/logon/sudo
  • moved user initialisation code into TWiki::User

11 May 2007

  • you can now use sudo login to log in as the configure admin both with templatelogin, and apachelogin as the primary auth ' though it depends on the use of CGI Session....
  • begun to use the 2 rego?supported and rego?enabled settings to disable the Registration topic.

18 May 2007

  • move loginmanager code into TWiki::User, that way mappings can even specify a loginmanager (most will probably not be plugable either)

23 May 2007

30 May 2007

  • finished group merging
  • TemplateLogin asks the mapper for which template to use (basemapper = login.sudo, twikiusermapper = login. , joomla = login.joomla , openid = login.openid) thus still allowing skin over-ride, and as those tmpl's should TMPL:INCLUDE{login} they only over-ride the inner UI
  • changed AllowLoginName=off to get user list from password file, and ignore the redundant TWikiUsers topic (fixes t.o issues)
  • re-write the get a list of all users code (for TWikiUserMapping) to WORKING
    • use only htpasswd file if AllowLoginName=off
    • use only TWikiUser entries with valid htpasswd file entries if AllowLoginName=on
    • and have all other user's fall back to be handled by BaseUserMapping
    • this should fix the twiki.org issues, and resolve the ambiguities in the old TWikiUser topic system.
    • users with an empty password in the htpasswd file are valid and active

4 Jun 2007

  • new session version of sudo login and logout, enables user to log in, then sudo to admin, then to logout back to their user - seems that at the moment you can sodo to anyone, and logout from apachelogin - interesting.

11 Jun 2007

  • using an extension the new Monitor.pm, I was able to see that by caching the results of getWikiName, the usermapping code became about twice as fast.
  • more integration testing going on, and work on making TWiki::Func cope better with the new cUID has begun.

17 Jun 2007

  • had to throw away the approach i was using for legacy cUIDs, as it was making the code confusing :/
  • trying to figure out why TWiki::Users:userExists is called with a cUID - surly a TWiki::Users::getCanonicalId shoudl return undef on non-existance!
  • unit tests of the understanding of legacy canonical_ids - This includes having TWikiUserMapping use TWiki-4.0/1 type cUIDs (I think the topic format version should be increased to show that topics now contain cUID rather than wikiname)

New contexts that will probably exist

  • DONE registration_supported - set if one of the selected UserMappers supports registration
  • DONE registration_enabled - set if the TWikiAdmin has enabled new user registration in confgure - won't apply to BulkRego? (enabled by default..)
  • sudo_admin_login - set if the TWikiAdmin has selected to use the SudoLogin feature
  • twiki_topic_groups - set if the TWikiUserMapping is used for group definition
  • twiki_topic_users - set if the TWikiUserMapping is used for user definition
  • template_login or external_login

-- Contributors: SvenDowideit - 09 Feb 2007 and onwards

Discussion

The LdapContrib has already the desired feature to exclude a list of users from being looked up in the LDAP directory. It has the default value of

$TWiki::cfg{Ldap}{Exclude} = 'TWikiGuest, TWikiContributor, TWikiRegistrationAgent, TWikiAdminGroup, NobodyGroup';

-- MichaelDaum - 11 Feb 2007

I agree 100% with the above issue.

I think the best way to setup the admin user is.

  • The configure script should walk through 2-3 wizard steps setting up the basic settings.

  • The first step should be what you today do manually setting the lib path in bin/LocalLib.cfg. It is totally mad that you have to copy a file and hack it. Configure script resides in the same directory as the configure binary so the configure binary should be able to save this setting.
  • The 2nd step should be the current Patch04x01 behavour showing the CGI settings and the General Path Settings. Once this is submitted the basic TWiki is working and we can go to step 3.
  • The 3rd step should be to define the admin username, wikiname and password. This way users using for example LDAP authentication can choose a their normal user name. What the wizard should do is:
    • Set a user name and password for the configure script itself. Once defined it should be required for viewing anything in configure. It will save yet another problem for the installer to specially protect the configure script with apache authentication in addition to the normal authentication.
    • Create the the user topic for this admin user and add to TWikiUsers
    • Add the name to the TWikiAdminGroup topic and set the ALLOWTOPICCHANGE to TWikiAdminGroup

it is not 100% straight forward to do this because we need to ensure that step 2 is working before we continue to step3.

But I see no reason why the creation of the admin user is done with confirmation emails etc. This is the step done by the installer and future admin and can be hard hacked into the TWiki once configure knows where the lib and data directories are located.

I think this 3 step wizard approach will cover the above needs expressed by Sven, Michael and many users that we help on #twiki every day.

  • Easier installation
  • Admin user name is not hard coded but defined by the user at installation. No question needed for default admin user. You are asked for it in the wizard.
  • The default TWiki wakes up safe and secure and the approach will work also when you later choose a different authentication approach like LdapContrib, or native Apache simple LDAP authenication or something completely different.

-- KennethLavrsen - 19 Feb 2007

Letting the configurator define a username is not as powerful as us hardcoding TWikiAdminUser and using the configure password.

Then, TWiki will be able to be shipped with TWikiAdminGroup set to contain TWikiAdminUser, and the Preferences topics will be secure at more points of an install.

The only remaining insecurity, would be if you unzip into your webserver, and then go home, leaving configure ready for anyone to set the password.

The other useful thing is, that TWikiAdmInUser would continue to work, even if the UserMapper has problems - both step 2 above not working, and if they mostly work, but a server goes down.

  • results in a 1 step twiki configure (go there, confirm paths, set password, save)
  • reduces support load (users ask whats the Admin user&pass, and we can tell them TWikiAdminUser and the configure password)
  • gives us a secure User we can hard code into TWikiAdminGroup (you never manage to avoid revealing the AdminUser because of this topic)
  • TWiki has some secure functionality, irrespective of LDAP or other external authentication systems

-- SvenDowideit - 19 Feb 2007

I'd like to add my support to this as an excellent idea. It's a common source of confusion for new users, who expect the configure admin user to also be an admin user in TWiki proper. It would also help to avoid the situation where a TWiki is improperly secured because the installer has been distracted from completing all the steps in the installation process (as recently pointed out by SueBlake).

-- CrawfordCurrie - 21 Feb 2007

I am all for this proposal.

An implementation question. How would we authenticate as TWikiAdminUser when there is also an alternative authentication in effect?

-- KennethLavrsen - 21 Feb 2007

I think the best way would be to "layer" admin status onto an already logged-in user. For example, you visit an "AdminLogin" page in TWiki web where you enter the username and password of the admin user, and it marks your session as being an "admin session". That way you keep your normal login (which is used by Apache, for e.g) , and there is that extra bit of auditability by the fact that you are really "KennethLavrsen(A)" and not just boring old "KennethLavrsen".

Details to be worked out by the implementor, of course wink

-- CrawfordCurrie - 22 Feb 2007

mmm, interesting idea Crawford. Unfortuantly, I don't think that approach would provide a default admin user if the UserMapping was broken, or a secured TWikiAdminGroup while configuration is in flux.

have to see what the code lets us do.

more added to the top - including a plan. This work i definatly not patch material.

-- SvenDowideit - 22 Feb 2007

One thing that I have seen discouraging potential developers is the confusing names used for the classes in this area. Any chance you could rationalise those as well? Since we are going to break all the existing password managers/user mappers, we might as well finish the job. For example, one approach I often use is to store subclasses of a base class in a subdirectory named the same as the base class:

LoginManager -> LoginManager::Apache
             -> LoginManager::TWiki
PasswordManager -> PasswordManager::Htpasswd
                -> PasswordManager::ApacheHtPasswd
                -> PasswordManager::LdapPasswordManager
                -> PasswordManager::JoomlaPasswordManager
UserMapper -> UserMapping::TopicsUserMapping
           -> UserMapper::LdapUserMapper
           -> UserMapper::JoomlaUserMapper
This is a lot more intention-revealing than the current knitting. Unfortunately it also involves an end-user configuration change, but I think we really have to bite that bullet.

-- CrawfordCurrie - 25 Feb 2007

This feature was discussed at the FreetownReleaseMeeting2007x02x26

  • AddTWikiAdminUser - Kenneth suggested a principle decision of the feature itself - not the implementation.
    • The release meeting agreed that the feature would be a great enhancement and that it is worth for Sven to continue working on the implementation
    • Implementation problem to watch out for were brought up
      • If we have a fixed name for the initial admin user - then it becomes difficult to authenticate this person when you use LDAP authentication and do not have any influence on a corporate LDAP server. Ie. you are not allowed to add users to this LDAP server. You only have one account for each employee. In this case it will be better to define the login name of the admin user in configure
      • If you define the admin user name in configure then configure will have to write the name of this user in the {SuperAdminGroup} topic and keep this group topic editable only to the {SuperAdminGroup} to maintain the idea of the proposal.
      • For more details see the attached transscript 14:39

Read the FreetownMinutes2007x02x26.txt around 14:39

-- KennethLavrsen - 04 Mar 2007

Suggestion: There is already an admin user named TWikiAdminGroup, used for statistics update etc. We can use this user; but better to rename that user to TWikiSuperAdmin or TWikiAdmin (naming a user topic ...Group is quite confusing.)

-- PeterThoeny - 05 Mar 2007

TWikiAdminGroup is not a user. It is a group.

And most admins will have used this group all over the place to limit access to settings and topics for the admins only. And it must remain a group because normally you have a small group of admins so everything does not stop when the one and only admin is ill or on vacation.

-- KennethLavrsen - 05 Mar 2007

TWikiAdminGroup is used as a group and a user. See WebStatistics, the change is done by the TWikiAdminGroup user, which is confusing.

To clarify, I am suggesting to rename the TWikiAdminGroup user (to avoid the confusion), and to keep the TWikiAdminGroup (aka group) as is.

-- PeterThoeny - 05 Mar 2007

OK. I understand now. Yes it is confusing. Agree.

But I still do not see how to implement an Apache based authentication with a hard coded TWikiAdminUser when you use a corporate LDAP server where

  • There is no chance in hell I can add a user called TWikiAdminUser to the corporate LDAP server.
  • There are more than one TWiki in the company and the admin user is not the same on the different TWikis. But there is one LDAP server common to us all.

So I really need to be able to define the username of the TWiki admin user like I do today. I will never be able to authenticate as TWikiAdminUser. But a user called TWikiAdminUser can exist for internal scripted actions like WebStatistics and other command line driven actions. But not as an authenticated user.

-- KennethLavrsen - 12 Mar 2007

There is nothing (that I can think of) in this proposal that will prevent a user from adding normal users to the TWikiAdminGroup after the initial installation is done.

I will have to take not of the TWikiAdminGroup 'user', as I think this should not be allowed for security reasons - otherwise, with an authentication system that is outside TWiki, it might become possible to create that user-group account, and then login with more rights than you should have.

-- SvenDowideit - 13 Mar 2007

The huge problem people have when installing TWiki is - they do not understand how to login as a admin. They do not understand that they need to register as a normal user and then make themselves an admin by adding themselves to TWikiAdminGroup. And when they finally do they probably often forget to remove the little #.

And I got the impression that this was the reason for this proposal in the first place.

If configure had the feature to create the first user as an admin - with a user name you choose and the WikiName. Configure would then add this wikiname to the TWikiAdminGroup and this topic safe and locked.

A different approach is to have an TWikiAdminUser and in configure have a field that maps a WikiName to this user.

This would allow the admin to register with a normal user name and normal WikiName. But the alias to TWikiAdminUser would give him admin status without being added to the TWikiAdminGroup topic. Then you can add more users to TWikiAdminGroup. The feature woud simple make the TWikiAdminGroup = {DefaultAdminUser} . TWikiAdminGroup

Then we can still keep the TWikiAdminGroup locked. The new user knows that when he registers with the WikiName he put in configure he is an admin. That may be a very simple implementation in fact.

-- KennethLavrsen - 13 Mar 2007

I want TWiki to be secure, even without configure 'creating' something. and So my plan is to have a default TWikiAdminUser, that is using the configure password, and does not allow loggin in until you have set a password. This user will be hard coded to be in the TWikiAdminGroup.

When you finally want to customise, you can add anyone you like to the TWikiAdminGroup, and go from there. There are alot of reasons this change is needed, it just happened that when i proposed it (for OpenID we need some non-remote default admin user that we can trust) a security issue was found that it would neatly solve too.

so no, I will not rely on configure being run to modify a topic (or set of topics) to secure twiki, and I desperatly want to remove the 'how do i log in as admin' support question too.

-- SvenDowideit - 14 Mar 2007

I do not understand how you will authenticate this hard coded user?

If I use Apache authentication towards an LDAP server there is no way I can login as TWikiAdminUser. You still have not come forward with a satisfactory answer to how you will address this without making the login name configurable so that I can change it to an existing user in configure.

Note: We have agreed on the feature but the spec is clearly not agreed yet.

-- KennethLavrsen - 23 Apr 2007

Suggestion: Call the admin user TWikiSuperAdmin.

Reason: Use a descriptive name for this root account. A large TWiki installation has many TWiki admins, "super admin" conveys the message that this is a special account.

-- PeterThoeny - 23 Apr 2007

That still does not answer the question. How do I authenticate myself with Apache authentication when this user does not and cannot exist in the corporate LDAP server?

I cannot add a TWikiSuperAdmin. How do I authenticate as c12179 and then link c12179 to the TWikiAdminGroup if I have to be authenticated as TWikiSuperAdmin to edit the TWikiAdminGroup topic? Other than hacking the file.

This proposal is about making it easier and safer. And that requires that you do not need to hack files to get started on a new installation.

-- KennethLavrsen - 23 Apr 2007

LDAP is not a new installation. its already gone way beyond it. I don't think that it will be an insurmountable use case, but i'm not intending on presupposing its implementation just yet.

-- SvenDowideit - 23 Apr 2007

No. But the installation does not become easier this way. It gets harder. And the the whole point is lost. But a configurable solution would fix it where the admin can add his login there and be hard mapped to be member of the admin group.

To get out of this deadlock - what do you propose Sven? You must have ideas. Peter also.

We do agree on the basic feature as a good thing. We just need the feature spec so it fits the use cases.

-- KennethLavrsen - 23 Apr 2007

I also would like to have a more crisp proposal documented in the document section of this topic.

Here is how I see it, YMMW:

  • Introduce a new TWikiSuperAdmin user:
  • TWikiSuperAdmin user is listed in TWikiAdminGroup by default
    • TWikiAdminGroup topic is locked down by default
  • Regardless of login manager used, this user always exists and has the password of the configure script
    • That is, for LDAP auth, all users are authenticated agains LDAP except this special user.

-- PeterThoeny - 24 Apr 2007

Let me be more practical and describe what I see as todays problems.

Installing a TWiki with normal .htaccess based authentication only

  • We assume we have taken the first steps and are ready to run configure. We also assume that you have used either the default http config file or a file generated by ApacheConfigGenerator.
  • First hurdle is that the newbie cannot run configure because it is password protected by the Apache authentication setup. The newbie admin now has to either turn off authentication in configure temporarily or manually create a .htaccess file the right place with a username/password pair typically generated by htpasswd command.
  • The user now runs configure, and saves the config including a password that has nothing to do with the password he just had to use to access configure. This is already confusing.
  • Now the user has to figure out how to become an admin. It is not obvious that he has to register as a normal user first. We have many questions about this.
  • Once the user is registered he can make himself an admin by adding himself to TWikiAdminGroup editing a normal topic, something he has never tried before.
  • And now it is critical that he knows he must remove the little # that disables the access rights to this topic.

Phew!

In the case where you setup Apache to authenticate against some central authentication ... like an active directory server or LDAP or authentication common with a CMS system like Joomla etc, all you have to do is change 3 lines to the apache config file (default or from ApacheConfigGenerator).

  • We have setup the apache config so that you Apache authenticates you when you access anything. And we have added ourself as required user for configure. This is all shown clearly in the default Apache config and in the ApacheConfigGenerator.
  • I run configure authenticating as myself with my corporate login
  • I save my configuration using a password unique to configure (extra security - maybe a little confusing to some)
  • I continue to my now working TWiki.
  • I register using my own name
  • I login using my corporate username and password.
  • I add myself to the TWikiAdminGroup
  • And slam the door behind me (removing the #)

In none of these steps did I have to create a .htaccess files, or hack text files or turn the need to login in TWiki temporarily.

Now if the TWikiAdminGroup topic becomes non-editable for a non-admin user, the above usecase is totally broken. There is no way I can get authenticated as a special admin user without temporarily fiddling the apache authentication setup. Something I would never waste time on. I would hack the TWikiAdminGroup topic at text file level. And all this trouble is JUST to enable blocking the TWikiAdminGroup topic by default. Who did we help in this case?

This is how I would like to see the use case no matter which type of authentication you run.

  • Inside configure there should be a feature to define the login name and wikiname of the default admin user (there is already a setting for WikiName which defaults to TWikiAdminGroup.
  • When you login to TWiki and you are not registered you have no wikiname but you have access like an admin has because your login name is defined as an admin in configure.
  • When you have registered, and login the Wikiname that should be shown when you edit and save and see your own wikiname must be the registered name and not the admin user name, because in a corporation, users normally only have ONE login name on the corporate directory and it is a pain in the butt to get a second. So the user want to be seen as himself. But he still has admin access because his username is defined as an admin in configure.
  • Additional admins can now be defined by adding them to the TWikiAdminGroup.

To me this resolves the basic issues.

  • People now known how to become an admin because that is clear in configure.
  • The TWikiAdminGroup topic can be locked by default
  • There is no need to hack any files
  • Authentication can be setup correctly from the start. We can even add the LDAP case to the ApacheConfigGenerator and maybe also the case for other Apache based authentications.
  • In an implentation where you do not user and group topic - the LDAP or whatever user and group that should be the admin can be entered in configure and things will run even more smoothly.

What it does not resolve is the .htaccess case where you have to find out how to get access to configure before you have registered your first user. It is difficult to think of a universally working automatic method. But that is out of scope of this proposal topic anyway.

-- KennethLavrsen - 24 Apr 2007

Does anyone else have a desired use case that differs from this?

In the end, Kenneth is asking for a similar ideal as I am working on, but to make it clear - the above may not be realistic and implementable, nor secure or what other sites want.

If you restrict the above's applicability to only TemplateLogin, it becomes a more realistic statement - Lavr, when you come back from holidays, can you clarify? Though I will be implementing it so that Lavr's compulsory case is actually optional, depending on the actual security needs.

-- SvenDowideit - 29 Apr 2007

Kenneth describes the current pain point clearly. However, instead of the proposed way of defining a user name in configure (and hoping LDAP integration works for auth) I think we can simplify the setup further with one predefined super user called TWikiSuperAdmin, same way like Unix. Benefits:

  • KISS - works out of the box, configure asks already for the super admin password
  • secure - TWikiAdminGroup can be shipped in a locked down state.
  • flexible - works with different login managers if the auth of TWikiSuperAdmin is done internally in TWiki

-- PeterThoeny - 29 Apr 2007

Ok, at this point in the code change, we could ship TWiki with the BaseUserMapping & TemplateLogin set as default - this would be a TWiki that has a TWikiAdmin that can log in, and a TWikiGuest that does not - with registration disabled.

I'm going to contiue to work at making the BaseUserMapping mix-in to any other Mapping, and to simplify whats there. (work in progres, but so far, develop seems to still be working, as do the unit tests)

-- SvenDowideit - 03 May 2007

Some facts

  • Simple LDAP authentication handled by an Apache server module only works with ApacheLogin. It does not work with TemplateLogin. When access of an admin user is needed TWiki redirects to the viewauth script and it is then up to the Apache server and browser to gain the needed authentication. It is for the same reason TWiki cannot logout a user when using ApacheLogin. The authentication is handled by Apache - not by TWiki.
  • With ApacheLogin the TWiki code does not ask for authentication. You cannot authenticate via ApacheLogin as TWikiSuperAdmin because this user does not exist in the corporate LDAP server.
    • Correct; and if your corporate LDAP server goes down, no-one can log into the TWiki. With a super admin user, at least one person can CC
  • A corporation like Motorola has probably 10 TWikis today. It is unacceptable that an admin of one TWiki automatically becomes the admin of the others. They have nothing to do with each other. So even if we could have a user called TWikiSuperAdmin it would be unacceptable security wise.
    • Hopefully not all 10 of your TWikis share a common configure password. Sven is talking about using that password for the TWikiAdminUser, as I understand it. CC
Remember that corporations is TWikis main target market and it has to work properly in a typical corporate environment.

You have not yet given a technical solution that WORKS without requiring ASCII file hacking (or the unthinkable temporary TemplateLogin hack) to get started in an ApacheLogin/LDAP or Active Directory or whatever authenticated installation unless you either

  • Keep TWikiAdminGroup topic editable by default
  • OR
  • Allow the login name of the initial admin to be configurable.

-- KennethLavrsen - 05 May 2007

I still favour the double login idea; first, login as a normal user. Second, visit TWiki.AdminLogin, and enter the configure password. You are then an admin for the duration of the login. This has a several benefits:

  1. works with template and apache login
  2. works with broken user mappers
  3. traceability of admin operations down to the individual who made themselves an admin
  4. admin activities are protected even in non-login TWikis
  5. totally compatible with default (TWikiAdminGroup) mechanism
  6. Easy to explain
  7. Easy to secure once initial install is complete (Set ALLOWTOPICVIEW = TWikiAdminGroup in TWiki.AdminLogin)
The implementation is easy in the context of the recent refactoring; 'isAdmin' is currently implemented by the usermapper behind the TWiki::Users facade. All that needs to be done is for the facade to check whether the session contains a verifiable token indicating that the user is acting as an admin (a crypt of the cUID and the crypted configure password should do it). (potential problem: if sessions are not enabled, the admin-ness would have to be remembered some other way)

-- CrawfordCurrie - 06 May 2007

Once your TWiki chooses to use Apache Auth, that pretty reduces what can be done for you. You've traded flexibility of use, for outsourcing the authenticaion.

  • What I can do today is fine. And this is not about ME. It is about not making TWiki a nightmare to setup for a newbie admin in our main customer segment - the corporate installations that often has outsourced authentication - KJL
  • This is like asking that the design and configuration of an enterprise LDAP system be one click simple. Rather missing the reality frown . I

If you decide to use LDAP auth, and choose to set {SuperAdminUser} to the same LDAP user, then that, again, means your choice is to have the same LDAP use as Admin for all those twiki's.

  • Irrelevant. You don't do that in practical. Each installer sets himself up as first admin independent of each other.
  • I'm glad that you too think the example you brought up above is irrelevant, but as you did bring it up, i thought i'd respond to it.
    • That is not the example I gave. I proposed that you could define the login for {SuperAdminUser} in configure. Not that every TWiki in the same company should have the same user ID. But that is an obsolete discussion because it seems we now work towards a better alternative implementation

mmmm, Kenneth, this is getting tiring.

  1. I'm not removeing what you can do today
    • Yes you are. I have described it in very detail what we lose -- KJL
    • yes, and you're wrong, I've tried to explain why and how you're wrong, and you're not getting it frown
      • No I am not getting it. Please try to explain instead just trying to describe me as an idiot.
  2. I'm adding more options, and making it easier for you to make more choces.
  3. You're complaining that I've not described how you can have what you can't do today, but list 2 options, the first that is insecure for the higher risk Installs, and the second, that you can already do.
  4. gawd, did you ever consider (option3) that if you do an LDAP based twiki, you set yout {TWikiAdminGroup} to be an LDAP defined group? I'm sure that if you tried to think of solutions, rather than focussing on being negative, you might actually get somewhere.
    • This assumes that LDAP groups is something the corporate little "fish" has any control over. LDAP groups in admin context is usually not an option. In my company I would not even know who to ask for it and the answer would most likely be NO! When you are in a 70000 people company these things are simply impossible because all these special needs are impossible to manage for the corporate LDAP admins -- KJL
  • no, it is only another example solution, there are many others that you claim are non-existant.

Now to Crawfords constructive suggestion: yep, that should be a pretty simple addition, the hard thing with all these changes, is to make it simple to configure, and to make the configuration simple to understand. We also need to work out how to make the AdminLogin (essentially a sudo) optional, and removeable.

-- SvenDowideit - 06 May 2007

I commented on Sven's in red.

You claim all the time that what you do will work. But you still fail to describe how it will work. Same with Peter. And I am happy that Crawford confirms my claim that you cannot both authenticate via LDAP and via an internal coded solution in the same authentication.

Crawford is the first to suggest a possible solution. You can do an additional authentication like Crawford describes. Ie. visitiing a specific topic creates an additional template like authentication which sets your session to be with admin priviledges. I like that idea. That might work well. And it will be easy to give the new installer a link to this login page from configure and from the AdminLogin page we can directly the now admin authenticated installer to the TWikiAdminGroup topic to add his normal username to the group. And on the TWikiAdminGroup we can have a link to AdminLogin. That will all help the newbie installer to get everything setup.

How would this be implemented Crawford? Would a new script be required in the bin directory or do you see it done in the code so it is a POST of a form to a normal view of AdminLogin that sets your login session to be an admin session?

-- KennethLavrsen - 07 May 2007

So far, I'm able to use the suggestions from Peter and Crawford constructvily, thanks guys.

Thinking further on adding an AdminLogin page, this is pretty much the same as telling TWiki to use TemplateLogin for some users (ie TWikiAdmin), either as a user, or as a sudo.

This brings me to an interesting implementation idea - not only do we get to 'mix' multiple usermappers, but we're talking about 'mixing' multiple Login types too. I could conceivably (somehow) configure TWiki to use mod_ldap_auth for most users, and configure it to use TemplateLogin for becoming admin, or for external temporary users / contractors...

Will be interesting to see how painful the huge number of options will be to configure though :/ . Thankfully, its not going to change the development plan I have, as its still the same code.

that gets us to needing to figure out how to present in configure:

  • use Admin User / login OR Sudo style admin OR both
  • use groups defined by one mapper, or from many, and whether groups rom one mapper extend the groups defined in others
  • users defined in one mapper, or from multiple, and what order to evaluate the login's existance in
  • use one login manager, or multipe, and in what order

some details wrt the SudoLogin idea

  • no user is in the {TWikiAdminGroup} - until they SudoLogin into it
  • we create a SudoersGroup - people that can see, and can SudoLogin
  • the TemplateLogin based SudoLogin UI can still be used to emergency log in the {AdminUser} without going to the normal user mapper/s

And this set of ideas brings me back to my original development plan, make everything pluggable - just put into new words.

-- SvenDowideit - 07 May 2007

of course there are 2 ways to SudoLogin - either by being in the SudoersGroup, and re-confirming your personal user credentials (like Sudo works on UNIX), or as a fall back for primary usermapping/loginmanager problems

-- SvenDowideit - 07 May 2007

I like the simple approach which I have the feeling both Peter and Crawford was suggesting.

In short bullets I think this would do the job:

  • The current way to become an admin is not changed. A user authenticated the normal way is an admin if his WikiName is listed in the TWikiAdminGroup
  • An additional login method is added with a hardcoded username TWikiSuperAdmin which uses the password used in configure.

This additional login method is meant only to "kickstart" the adding of regular WikiName(s) to TWikiAdminUser. And as Crawford mentions - when a corporate LDAP or whatever server is down - it allows an admin to login as an admin and maybe temporarily open unauthenticated access to one or more webs.

I think we should avoid implementing a very advanced admin feature and go for a simple and easy to explain solution.

Crawford - I would still like to hear your thoughts to the actual technical implementation to your proposal. Just a brief 2-3 lines description.

-- TWiki:Main.KennethLavrsen - 07 May 2007

FreetownReleaseMeeting2007x05x07 decision was to ask Sven to clarify spec before we can make a decision

-- KennethLavrsen - 07 May 2007

I believe I already described the implementation at #MakeMeAGodInSevenDaysOrLess. To make it clearer from a user perspective here's how a newbie would get started:

  1. Install TWiki. Assume Apache login manager, with no require valid-user on view script
  2. Set a configure password
    1. Note: might be a good idea to require a configure password - or at least make the warning more aggressive
  3. Visit TWiki.MakeMeAnAdministrator
  4. Enter the configure password
Public and other paranoid sites:
  1. Protect configure using Apache
  2. Flick a switch in configure to block all access to TWiki.MakeMeAnAdministrator
TWikiAdminGroup is still used, but it is now just a normal group - it doesn't confer special (hard coded) rights. If I protect TWiki web with
  • Set ALLOWTOPICCHANGE = TWikiAdminGroup
that allows me to define the set of people allowed to change the system (and plugin) topics. It does not give those same people access to configure. But if I have the configure password, I can do anything (because isAdmin is true).

The implementation is IMHO fairly straightforward, apart from the issue of what to do when sessions are disabled.

-- CrawfordCurrie - 08 May 2007

if you change TWiki.MakeMeAnAdministrator to be the templateLogin UI, you have what I'm doing. There's no need to make a new dialog at all. Implementation issues surrounding which cUID to use for a user that is straddling two Mappings, and how to not surprise users that set DENYTOPICVIEW=JoeBlog, but have it modified by JoeBlog (A) will also need some working out.

BTW, the current implementation of BaseUserMapper already refuses to log you in as admin unless you have set the password. Its not compulsory for configure, but it is compulsory if you want to log in as our newmagic admin.

Now that I have (i think) confirmed the plausibility of this technically, this is what you may see

  • when the primary auth (templatelogin or apacheauth, or some other external auth) is working fine, the user can
    1. login as their normal user
    • if that user is in the {TWikiAdminGroup}, they are isAdmin
    1. if not, they can click on a SCRIPTURL{log[io]n}?sudo=sudo link, which takes them to a templatelogin based UI, and can auth as {TWikiAdminUser}
    • Crawford and I hope to display that user as JoeBlogs (Admin) or TWikiAdmin (JoeBlogs)
    • I am contemplating a SudoersGroup, that the user would need to be in to be allowed to promote themselves
  • when the primary auth is broken (DEFERed)
    • they can click on a SCRIPTURL{log[io]n}?sudo=sudo link, which takes them to a templatelogin based UI, and can auth as {TWikiAdminUser}

as you may see from my recent commit, the code in logon and login are now identical, and though the backend is not wired up, ?sudo=sudo already shows the templatelogin when apachelogin is used as the primary auth method.

(added todo for twiki cgi script)

-- SvenDowideit - 08 May 2007

I like what I see now. THAT will do the job for everyone.

I have no more concern if Sven's last proposal is the way we do it.

It is important as Sven mention that a person with his WikiName in the TWikiAdminGroup is still isAdmin without having to do further logging in. And it is also important that there is still a difference between a normal admin who can edit any topic no matter what ALLOW or DENY is setup and giving access to configure.

E.g. I have given TWikiAdminGroup status to several users but I have not given them full access to install plugins.

It seems with Sven's proposal we all this. I am very happy with the result.

I now change the status to accepted / consensus reached.

That does not prevent further technical implementation discussions here or on a bug item but I see no more open concerns that should block Sven from doing the implementation.

-- KennethLavrsen - 09 May 2007

I have a minor niggle; I don't actually like if that user is in the {TWikiAdminGroup}, they are isAdmin. I quite like the idea of a user group that can - for example - edit TWikiPreferences, but can't (for example) reprev. The extra excise of a second login to become an admin seems to me to be a positive; it makes it clear that an admin is something special, and you should only be there if you really have to be.

On the other hand, it could be a real pain for a TWikiAdminGroup member to find a topic protected against them, which could happen if it is just a simple group. So, I think both approaches are workable and would be fine with either.

I'm slightly disturbed by how few people have commented in this topic; for such an important issue, potentially affecting everyone who admins a TWiki, I'd have hoped for a few more comments from the community before we could claim 'consensus'.

-- CrawfordCurrie - 10 May 2007

if you don't like if that user is in the {TWikiAdminGroup}, they are isAdmin then set {TWikiAdminGroup} to something impossible to be a member of like and empty strig smile

TODO - make sure that {TWikiAdminGroup} = '' never has members, irrespective of how clever hackers are.

wrt feedback, I've bullied a few people on IRC into giving me some, hi Gordon, Demi and ..... argh - the other 2 :).but Yes, I also worry that there are some obvious code paths that are needed by someone, but if they don't speak up, what can we do.

-- SvenDowideit - 10 May 2007

I really do not want to loose the current spec that enables me to have a number of users that can edit ANY topic no matter what access rights have been set up. There is always someone that shuts himself out of a topic by setting access rights wrong and therefore also shutting out an "admin" group which is just a group. So with todays behavior of TWiki I can safely have 3-4 trusted people in the admin group. But I still want to holy configure script limited to just me mainly to have tight control of which plugins are installed to avoid poor quality plugins.

Everyday life with a living TWiki for quite some years now has taught me that a TWiki cannot be admin'ed by only one admin. I am either on vacation, on business trip, in a metting, or sleeping and the user in trouble is in another timezone when someone needs an admin to fix an access right problem. Then it is good that we are 3-4 people so there is always at least one that can help and it works very well. But installing a new plugin can wait till I am available.

Also on my public Motion TWiki it is good to be a couple of admins to remove spam with delRev. And again there I want to be the only one that can touch configure. Sven's current proposal addresses the original intention with this feature request well and maintains current behavior of how the admin role works.

With respect to consensus. Yes. It would be nice with more feedback, but reality is that people hide and let the usual work horses do the hard work including the discussions. If we have to wait for consensus from everyone then this release process is not going to be efficient and fast. This topic has been discussed also at release meetings so I think it got the attention it needs - and more.

-- KennethLavrsen - 11 May 2007

I changed state to under construction.

Sven can you in a few bullets describe what is missing?

And when you expect to be done?

I would like to start testing this but I do not want to start until the feature is complete. My impression is that most of the code is there.

-- KennethLavrsen - 28 May 2007

the entire time i've been working on this, I have been keeping the todo bullet list up to date. it still is uptodate. sadly, it takes a day of testing every 10-20 lines of code i commit.

-- SvenDowideit - 29 May 2007

The way it is currently implemented it is

  • A near impossible maze for a newbie to become an admin.
  • It does not work with ApacheLogin - which I predicted.

Only way currently to become an admin is to hack the TWikiAdminGroup at file level.

Both the "story" of how the person becomes an admin needs to be reviewed so it becomes easy and not a nightmare. And the authentication.

I have proposed the solution above.

The configure script should have a section with "Adminstrator User"

In this setting you define the login name of who you want to be administrator.

And then when you later login as this name (after registration if registration is enabled or simply after having logged in using your LDAP login) you are the admin. Additional admins can be added to the TWikiAdminGroup topic. Or why not make the configure setting allow a comma separated list of logins. Then we can let go of the TWikiAdminGroup topic as a group topic and replace it with a simple topic without a GROUP setting that explains that the admin group is defined in configure.

In the code all that was needed was

  • Add the configure setting in LocalSite.cfg
  • Change the code so that the TWikiAdminGroup is defined by using the configure setting instead of the normal group. There is already code that decides if you are an admin. It cannot be many code lines to check if the authenticated user is in the list of names given in the configure setting.
  • Change the TWikiAdminGroup to a locked simple doc topic referring to configure.

This will work no matter what kind of user mapping or authentication you are using.

Sven said on IRC that I am the one that "cries wolf". Well. There is a wolf! A whole pack of them. Bug is tracked in Bugs:Item4204

-- KennethLavrsen - 04 Jun 2007

Reading this topic again, it looks to me like you're ignoring the steps indicated on 8 May - that seems to me to be the begining of the technical version of the docco. Which from my recollection was what we'd had some consensus on, and Just happens to be how it works (or did some time last week)

Now that I've spent trying to work out how to respond to Kenneth, rather than working on completing the code change, so that I can begin to work on making the user interface trivial, it seems to me that this is pretty much just a personal attack frown

simple fact is, I resisted writing too much detail until my post of the 8th of May, precisly because I was worried that someone would insist I implement the impossible, or predetermine the implementation to be something that would become similarly limiting.

*It does not work with ApacheLogin - which I predicted.* is a Wolf cry. It worked under ApachLogin on the 8th, and I think until some time last week, when I began working on a cleaner codebase. Since then I've found a much cleaner way to make sudo work, but I can't commit it until I've had time to finish it, and test it to my satisfaction.

There seems to me to be an ancillery complaint from Kenneth, that the DEVELOPMENT code (currently known as MAIN) is in steady development. This, as far as I can recal, is because Kenneth was one of the loudest voices against the developer's proposal of multiple development branches.

yep, another delay.

-- SvenDowideit - 04 Jun 2007

Yes I tried to be positive and supportive round the 8th of May to get a compromize decision.

Now that I have tried the actual use case I can see that this ends up being unnecessarily complicated and confusing. We can patch it with documentation but it will always be confusing. And that is what I am voicing now. I'd better do it now than after we release 4.2.0.

And the wolf is there biting us at the moment with the code not working with Apache authentication. I do not think it is healthy to try and mix two authentication methods and we will fight with it forever.

On branches and code stability?

Yes I was and still am against having a branch for next major release and one for next minor and one for patch. Our community does not have the resources to maintain more than the two community branches we have now: MAIN and Patch. And with the rate people seem to disappear from the project currently even the Patch branch is not maintained. The problem is that a few developers check in incomplete code and refuse to revert it when it does not work leaving the core features broken for long periods of time. That may not be a problem if you are only 2 people active. But you cannot be 10 or more working on developing different features in parallel if the basic code base is constantly broken. This is probably why mainly 3 people in practical are active right now. Two on the core. One on skin. Where are the others? Are they waiting. Have they left for good? Will they come back?

Developers needing a scratch pad to share with someone else can always create a temporaty private branch and then merge code into MAIN when it is stable. There will always be bugs in new code and noone is perfect. But we can all make an effort and try and keep our common resource - the precious source tree - as stable as possible so the others can work as well on something that is stable and with unit tests that pass.

-- KennethLavrsen - 04 Jun 2007

2 quandries:

  1. if a topic contains a non-existant user, we currently (v3, v4 etc) display some literal version of whats there - resulting in things like Main.skenny considering that full removal (ie from TWikiUsers etc is recomended against, this would mostly be spammers / other undesirables. Do we want to consider making those UnknownUser or something similar?
  2. historically, the user code always returns a user - falling back to 'guest' if need be - this makes it harder to have a concept of non-user (for eg, if you ask for the WikiName('nonexistantuser') it would be equally valid to return UnknowUser, guest or nonexistantuser. Similar issues arrise if the system asks for user related information of a group - a somewhat undefined thing too.

-- SvenDowideit - 13 Jun 2007

Bugs:Item4204 was closed with no action with the words "nothing to be done, this bug report is mostly based on reporter ignorance". A clear personal attack on me being the reporter.

I have been reporting a problem both with the

  • User case - it is simply too difficult to figure out how to become an admin. Even harder than it was before.
  • It still does not work with Apache authentication because the edit script is triggering an apache authentication for a user that is not in the .htpasswd file. Like I have said from the beginning.

I want this feature brought up at a release meeting in near future. And I urge others to try a fresh TWiki setup for Apache authentication as described in the installation docs and the default twiki_httpd_conf.txt/.htaccess.txt files. And then try if you can become an admin. Both if it is easy for a newbie AND if it is possible at all without hacking the TWikiAdminGroup topic at file level. It is important that you try with a default TWikiAdminGroup topic where your normal login is not present. And naturally you need a fresh .htpasswd file.

-- KennethLavrsen - 13 Jun 2007

By "accident" I discovered that if you login first as a normal user. And then does the SUDO login with TWikiAdminGroup as user name configure password as password then you can edit the TWikiAdminGroup topic.

And then I tried with a fresh browser to do the SUDO login first. And then login as KennethLavrsen normal user. And then I can also edit.

So the secret is that you need to SUDO authenticate with TWikiAdminGroup/configure password and Apache authenticate with a valid user from .htpasswd to gain access.

This is not at all obvious. But it changes Bugs:Item4204 report from impossible to difficult

If I as a very experienced user cannot figure it out then many others will have the same problem so we have to do something about it.

These are the minimal steps needed.

  • done.gif - From configure we need a clear path how to get registered and how to become an admin user.
  • done.gif - The documentation in the TWikiAdminGroup topic must be updated to clear say that you should be registered first with a user name and logged in as this user name.
  • The SUDO login must return to TWikiAdminGroup topic and not to Main as I also described in the original bug item text.
  • done.gif - The SUDO word is Unix geek language that only few Unix/Linux admins know. The description used in docs should use a more commonly understood word. Administrator login. It is OK to use sudo in the url. It is just the link text that should be changed.

We have had so many questions in the Support web and in the IRC from people asking how to become an admin. And it has not become easier with this. So it is important that we get the documentation and the behavior (return to TWikiAdminGroup after login) right.

We need a natural flow from configure complete through first registration and ending with being added to TWikiAdminGroup.

UPDATE

I have done the doc part. Sven you need to fix the sudo login so you return to TWikiAdminGroup (or rather return to where you came from).

-- TWiki:Main.KennethLavrsen - 14 Jun 2007

So, we've again gone through the OMG, nothing works and the developer is a moron, back to, some docco written and it does work. Kenneth, will you ever become less insulting. The even worse impact of your beahiviour, is that its discouraging discussion on important questions.

Choice.

ATM, I'm still working on writing unittests, because I want to make sure there is some way to know about the subtle corner cases. As you can see, even without my having written Documentation, you are able to work it out, and document some.

FEEDBACK and DSICUSSION REQUIRED

2 quandries:

  1. if a topic contains a non-existant user, we currently (v3, v4 etc) display some literal version of whats there - resulting in things like Main.skenny considering that full removal (ie from TWikiUsers etc is recomended against, this would mostly be spammers / other undesirables. Do we want to consider making those UnknownUser or something similar?
  2. historically, the user code always returns a user - falling back to 'guest' if need be - this makes it harder to have a concept of non-user (for eg, if you ask for the WikiName('nonexistantuser') it would be equally valid to return UnknowUser, guest or nonexistantuser. Similar issues arrise if the system asks for user related information of a group - a somewhat undefined thing too.

-- SvenDowideit - 14 Jun 2007

I have never said that you are a moron. I discuss the feature and had to be very persistant to get a spec defined and a solution described for the authentication problem that enabled the community to accept the feature. We eventually got to that point.

When I tested what you had implemented - it did not work and I raised a valid bug item. The feature was broken when I raised it. The authentication did not work when I raised the bug. And it was the issue I had raised my concern about.

Then a few days ago you reject the bug item with "nothing to be done, this bug report is mostly based on reporter ignorance". That made me quite upset.

The bug item addressed the entire use case - I had a hard time separating it is several reports without loosing the context. It addressed

  • The use case that was too difficult (going through a maze to become admin) and with lack of docs
  • The authentication issue - which has been fixed meanwhile but I did not realize first time I tested because I had forgotten the intended spec described above and the help text on the TWikIAdminGroup topic had not been updated.
  • The redirect issue which amplifies the "maze" issue.

What I am upset about is your personal remarks like "So far, I'm able to use the suggestions from Peter and Crawford constructvily, thanks guys." (anyone can read between the lines what that meant), "the one that cries wolf" and "nothing to be done, this bug report is mostly based on reporter ignorance". I am OK with debating the technical issues. But personal attacks make people leave the project.

I still have the opinion that this feature could have been implemented in a more user friendly way and in a way that would have avoided the SUDO authentication, by having the login for the admin user defined in a simple configure setting. And I hope I am entitled to have this opinion. I can live with the current implementation once the last bug is removed, but I still find the process of becoming admin more complex for the newbie than it need to be. And I fear that the code complexity creates a risk of new bugs in future. The support questions we will get and the bug reports that gets raised will tell. For 4.2.0 we go with what is implemented now + the redirect issue fixed.

-- KennethLavrsen - 15 Jun 2007

Hm, does anybody else think Kenneth takes his job as CustomerAdvocat (which he does great by the way) a little too seriously lately? Heh, shouldn't TWiki development also be fun? Sven is rude (no offence wink ) as we all know, don't take it too personally.

-- FranzJosefGigler - 15 Jun 2007

Kenneth, i sympathise with your being upset, however, note that every time I have written such, its because you have upset me, and I could not find a way to tone it down. So please, stop writing stuff as though I'm the only guilty party - including your last post.

for eg: And I fear that the code complexity creates a risk of new bugs in future, or It does not work with ApacheLogin - which I predicted. I guess that the 3-4 weeks of accusation that my changes broke the table unit tests, when it had nothing to do with my changes, really put me into a bad frame of mind.

In the end, I've found it necessary to just ignore most of what you write, as its written too agressivly for me to be able to use productivly - and as such it too much of a personal attack from you.

yes Franz, I'm rude, but really, not in isolation.

-- SvenDowideit - 15 Jun 2007

FEEDBACK and DSICUSSION REQUIRED - (yes, without answering these questions, development will not be finishable)

2 quandries:

  1. if a topic contains a non-existant user, we currently (v3, v4 etc) display some literal version of whats there - resulting in things like Main.skenny considering that full removal (ie from TWikiUsers etc is recomended against, this would mostly be spammers / other undesirables. Do we want to consider making those UnknownUser or something similar?
  2. historically, the user code always returns a user - falling back to 'guest' if need be - this makes it harder to have a concept of non-user (for eg, if you ask for the WikiName('nonexistantuser') it would be equally valid to return UnknowUser, guest or nonexistantuser. Similar issues arrise if the system asks for user related information of a group - a somewhat undefined thing too.

If it doesn't break things in public webs (no registration needed to edit), I would take the UnknownUser path.

-- RafaelAlvarez - 15 Jun 2007

Agreed. See also Bugs:Item4252

-- CrawfordCurrie - 16 Jun 2007

To quickly summarize the issue from Bugs:Item4252 that I think extends Rafael's quandries: Will it be possible under the new system to deal with somebody who is not registered with TWiki but authenticated over some other means (Apache auth in our case) as to provide a sensible fallback on the login name of the user if no wiki name exists for the user?

-- ChristopherOezbek - 16 Jun 2007

Rafael and Christopher, can you please be (painfully) specific about the 2 use cases you are talking about? I fear that there are details that need to be made into very specific testcases, as the more I try to improve the performance, the more specific assumptions i would encode.

use cases

Anonymous

  • TWikiGuest user is recorded as editing
  • in 4.2 the BaseUserMapping adds a TWiki Admin user, and makes it possible to remove the TWikiUsers topics and the registration systems

TWikiUsers topic based (using htpasswd file for logins)

  • All users are registered using TWiki
  • uses .htpasswd file for login
  • if AllowLoginName is off, LoginName is the same as WikiName, thus TWikiUsers Topic is redundant and in 4.2 the user's existance is only read from the htpasswd file (like on TWiki.org)
  • if AllowLoginName is on, the TWikiUsers topic is used to map the login name to WikiName (thus incurring the double penalty of reading the htpasswd file to log in, and then the TWikiUsers file to map
    • I'm contemplating moving this to the htpasswd file, but it is really too late

Christopher's example: Kerberos/Apache for Auth and TWikiUsers for mapping to usernames

  • Background: Everybody who is authenticated using Apache (via Kerberos in our case) can edit topics, independent of having registered with TWiki.
  • Expected behavior:
    • If user has registered with TWiki (TWikiUsers contains ChristopherOezbek - oezbek@PCPOOLPLEASENOSPAM.MI.FU-BERLIN.DE - 23 Aug 2004) then %WIKINAME% should evaluate to ChristopherOezbek, %USERNAME% should evaluate to oezbek@PCPOOL.MI.FU-BERLIN.DE, %WIKIUSERNAME% should evaluate to Main.ChristopherOezbek
    • If user has NOT registered with TWiki (TWikiUsers contains no mapping), but the user is authenticated via Apache as oezbek@PCPOOL.MI.FU-BERLIN.DE, then %WIKINAME% should evaluate the same value as %USERNAME% which should evaluate to oezbek@PCPOOL.MI.FU-BERLIN.DE, %WIKIUSERNAME% should NOT evaluate to Main.oezbek@PCPOOL.MI.FU-BERLIN.DE but rather either to just oezbek@PCPOOL.MI.FU-BERLIN.DE or something like [[Main.TWikiRegistration][oezbek@PCPOOL.MI.FU-BERLIN.DE]] (Main.TWikiGuest should not be used in this case, because we want to see in the logs and revision history, who made the edit).

  • Current behavior is to sanitize the username: oezbek@PCPOOL.MI.FU-BERLIN.DE becomes DE (everything past the last . I imagine).

-- ChristopherOezbek - 18 Jun 2007

LDAP

Joomla User Mapping

  • replace the TWiki User Mapping with a Joomla User Mapping
  • requires Template login, and uses the Joomla database to get login, group membership, and a not unique 'Display Name' that can be used as WikiName

OpenID User Mapping

  • replace the TWiki User Mapping with n OpenID User Mapping
  • requires Template login, and uses openid to acutally log in, and attempts to get a not unique 'Display Name' that can be used as WikiName - if the user is using an older OpenID server, or has not filled in / or given permission to access that information, it may need to fall back to displaying the openID URL.

Corporate Legacy Solution

  • Uses custom login manager, password manager and user mapping
  • Login is redirected to a corporate authentication server
  • Login is by "friendly user ID"
  • Authentication server sets up authentication cookie, that contains "company user ID" (different to friendly) and redirects to provided URL
  • "Company user ID" is required to retrieve first and lastname to build user display name, and for group membership queries
  • Lots of users and huge groups (big company) so all user queries must be just-in-time

PLEASE add other use cases

in short, the bugger is in the details - the more detailed cases that are documented, the more we can write unit tests to prove, and thus also benchmark.

-- SvenDowideit - 17 Jun 2007

By reading the use-cases, I noticed that it was a misunderstanding of mine. Public wiki's (both totally public and those with some restricted areas) are covered. Anyway, if someone, somehow, ask for the WikiName of a non-existant user, I agree that something in the line of UnknownUser should be returned.

-- RafaelAlvarez - 18 Jun 2007

I'd suggest to add a %TWIKIREGISTRATION% preference variable that defaults to %TWIKIWEB%.TWikiRegistration to ease customization of the registration form without touching the original one in the TWiki web. This needs coordination with the registration_supported and registration_enabled context vars in a way, for example, that registration_enabled is set to false if %TWIKIREGISTRATION% is empty. Could be implemented in the standard login manager.

-- MichaelDaum - 22 Jun 2007

Why use a preference variable? Why not use a TWiki::cfg?

-- CrawfordCurrie - 23 Jun 2007

The third option is that its a setting that is defaulted by the UserMapping, but over-rideable (so that each of the mappings have their own sensible default, and then customisation can be done later - much like template login's template is set buy the mapping atm).

I'm also wondering how to tell the skins that a wikiname IS NOT a topic - such as in Christopher's case - right now, the skins use [[]] to force a link for the displayed username, and similarly, there are issues (if i recal correctly) in the $wikiname outputs in SEARCHs.

-- SvenDowideit - 23 Jun 2007

Any user displayed in TWiki should link to his profile. The current way this is done is via his/her WikiName which happens to be a WikiWord that resolves to the user's profile stored in a topic the Main web. This means that you end up with a huge Main web and a long TWikiUsers topic. Both is bad. (TWikiGroups is also bad for large user bases but that's another story.)

One could easily imagine to implement a UserMapper that stores all users in a database and displays its profile by means of a special url, something like

http://my.company.org/profile?user=id77810
. So the correct way to get away with user topics would be to let UserMappings define how to display a user profile. In case of the default TWikiUserMapper this will be a WikiWord that links to his topic in the Main web.

-- MichaelDaum - 01 Jul 2007

Any user displayed in TWiki should link to his profile. is not true - there are use cases where they don't want user names to link to things.

But I like what you are sugesting - if I change getWebDotWikiName() to return [[user url][WikiName]] then we have what you and I are heading for. The only thing to figure out, is what that will break frown - and one is things like the User's leftbar ....

so I guess we'll need a new %USERINFO parameter and TWiki::Users::getUserUrl() - which for TWikiUserMapping would default to Main.UserName, in Joomla might goto Joomla's user page, and in OpenIDUserMapping would point to the OpenID URL

-- SvenDowideit - 02 Jul 2007

Makes sense to me.

-- CrawfordCurrie - 02 Jul 2007

Sounds really good!

What would getWebDotWikiName() return if no user url is given (as in my case of the users that are unregistered with TWiki but that have a Login-name)?

-- ChristopherOezbek - 02 Jul 2007

Hi Guys,

Just a PING to ask what the status of this change is.

Many greetings from Berlin,

-- ChristopherOezbek - 23 Aug 2007

we had to stop making further deep changes, to get 4.2.0 released - I hope to pick this up for next time (unless someone else gets there!)

-- SvenDowideit - 17 Sep 2007

Edit | Attach | Watch | Print version | History: r97 < r96 < r95 < r94 < r93 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r97 - 2007-09-17 - SvenDowideit
 
  • 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.