Question

I have it so that users can authenticate via LDAP. I have installed the LdapPlugin and can query successfully. What I'd like to do is make it so that after authenticating, users without a WikiName must create one, something like TWikiLdapRegistration. Unfortunately I don't understand how to implement this, or if it is even possible.

If you've done this can help me get started that would be great!

Environment

-- ToddSlater - 19 Apr 2006

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Time passed, closing this as unanswered.

-- PeterThoeny - 01 Jun 2006

Reopen Question

I also am asking this same question, so I would like to re-open this topic. In TWikiLdapRegistration, JohnVanBoxtel writes:

I just force Apache to require valid-user for edit, diff, etc. This auths them against LDAP (eDirectory in our case). Since they don't have a WikiName until they register, it won't let them edit anything, and sends them to the registration page . . .

This makes no sense. With an .htacess file, I, too, force Apache to "require valid user" for edit, diff, etc, which "auths them against LDAP." But if the user does not have a WikiName, it still lets them edit. Their signature is just their LDAP username instead of a WikiName.

So, how do you force an LDAP-authenticated user to register?

I suppose using that approach would be site specific (policy or paranoia). We also use LDAP authentication for our site, but because we have users all over the world and in different groups (engineering, marketing, localization, etc...) it seemed like it would be counter intuitive and counter productive to force users to register. However you could build some condition checking into the template pages for your webs (all your pages would need it, otherwise those that don't have the condition, break the ability to enforce the rule). Here's an example we use in the main web (not a redirect though):

%IF{"$WIKINAME = $USERNAME and not defined $USERINFO"
then="<b style='color: red; text-decoration: blink'>Attention:</b>
<b style='color: red'>The next step for you to do is become a registered user with this wiki server.</b><br />
You have not yet registered on this wiki. Although you have been authenticated as a valid user, you cannot participate and
make contributions until you have registered with the wiki server itself. [[TWiki.TWikiRegistration][Please register right now]].
<br />[[Main.RegisterPromote][more...]]"}%

As you can see the register now link simply sends them to the registration page, and then the more... link goes to a page that explains why it is a good idea to register and what benefits they will gain from registering. You might want to play with a combination of this and the META plugin (I forget the link to it). You could come up with some condition that might use the refresh meta tag and so force the page to refresh to a particular URL.

Depending on how you setup your site, you can implement motivation for users to register (and to be honest with you most users usually do want to register, it's really a matter of familiarizing themselves with the application). What I mean is that for our wiki, we seperate the authentication and access control functions (and I think that is probably the intended idea). So authentication is done via LDAP (you are indeed who you claim to be), but then access control is established with your WikiName, so if you don't register then you can't view/edit project pages. Pretty soon the word gets around and the amount of questions regarding not being able to see such and such project page diminishes because the reason for the issue becomes tribal knowledge and the users themselves start helping each other. Also if you setup access control in this way you basically give control to the project leads/managers which seems to make them very excited. Then when they have someone they need to include on a project, they get to add them to their access control for their project page. In the end I have a nice and neat, self sustaining community that suddenly does not need me any more, and now I can go surfing out at the coast; and life is good. Sweet!

-- RobLeach - 12 Jun 2006

Thanks Rob for sharing your thoughts.

Automatic registration could be done in a Plugin. Whenever a user tries to to some action that requires identidy (edit, attach, etc), the Plugin checks if the user has an account. If not, the Plugin transparently creates an account for the user based on information in LDAP.

On access control, collaboration works best if there are not too many access restrictions. From a collaboration perspective it is best to have no access restrictions. If required, consider locking content down to bigger groups, e.g. to the whole engineering department instead of little groups.

-- PeterThoeny - 12 Jun 2006

Most definitely you're right Peter. Callaboration is best done in an open access environment. One of my favourite topics to talk about with my fellow employees is the Cathedral and the Bazaar idea. For me personally it revolutionized my thinking about collaboration. But unfortunately corporations don't see things that way (to their loss). And so as messy as democracy is, I need to give the engineering community I work with, what they want even though I know there is a better way.

Just like you said creating large groups that have access control is by far the better way to go. The way we've finally settled on implementing group access is by this: if you're in engineering then you have access to all project webs. However we still have one group that is so immensely apposed to this, that they have their own hidden world (to give them credit, their project is high security).

But again in the end my goal is to establish a community (even a corporate community) that can basically run itself. Just as much as having open access is a good idea, I think having accessible administration is also good (I said accessible not open, that could create some issues of it's own—even in the Cathedral and the Bazaar idea there was a team/project lead; someone needs to take responsibility). I'm sure that is brought home for you personally many times, right Peter....

-- RobLeach - 12 Jun 2006

Peter, an LDAP automatic registration plugin would be very popular. And based on the number of topics like this one, it is needed sorely. Yes, this is open source, and if I want it why don't I write it. Well, I don't know Perl.

I hope someday to find the time to learn Perl, but besides that, what ways can we encourage the construction of an LdapAutomaticRegistration Plugin?

-- AndrewBanks - 13 Jun 2006

The canonical way would be to snatch one of the CodersForHire. LDAP settings need a bunch of site specific configuration data (server name, query specification, base, authentication info), so I guess that a solution which fits your site might be a lot easier to implement than a generic plugin. If that is out of reach for monetary reasons all you can do is be patient (today another subroutine used by RegistrationOnDemandHack has been renamed. No convergence in sight)

-- HaraldJoerg - 13 Jun 2006

This was an issue for us as well. I created a RequireRegistrationPlugin that will push users with a non- WikiWord username to the registration page. Thanks to Peter Thoeny for the hint that helped me create my first plugin.

-- ByronIgoe - 27 Jul 2007