This plugin allows the use of server side variables to be used during the login process and therefore use an external Identity Provider. In situations where separate AuthN and AuthZ is required, this allows the use of internal group access and definition within Dokuwiki (AuthZ) and allows you to use tools like Shibboleth as AuthN providers to the installation.

Configure your server-side authentication mechanism and prove that it is setting the correct server variables. You will need these to set the plugin fields for UserId, Name and Email address. An example set of shibboleth variables may be:

  - SP_USERID
  - SP_DISPLAYNAME
  - SP_EMAIL

I recommend using shibboleth authentication to do this with apache

FixMe: Write a guide for setting up shibboleth and apache2

Search and install the plugin using the Extension Manager. Refer to Plugins on how to install plugins manually.

Or use the download link above, and paste the URL into extension manager's “manual install” URL box.

After installing, enter <box>Admin→Configuration</box> and set the correct location of the user file. This file must already exist (it will not create it if it doesn't already)

Set the name of the user variables. Inspect local variables if necessary and ensure that you have a username that matches an Admin group user in the existing plainauth users file. Without this, when you switch over, you will have default user access unless you can also access and edit the file on the server console (ssh etc)

Change authentication mechanism to authserversso when you are happy and away you go

The source code of the plugin is available at GitHub: https://github.com/majic79/dokuwiki-plugin-authserversso.

I originally cobbled this together in 2018 for a “Weatherwax” internally hosted site. When we moved to a new server, we upgraded and tried to use an already supported plugin authshibboleth but had some problems with user groups not working the way we wanted (expanding the IdP to include groups was not feasible) so I decided to revisit some old code.

I'd like to give credit where it's due - very little of it is my work (I'm not a PHP programmer, I got hints from authplain and learnt a few things along the way before forgetting them) but I cannot recall where all of it came from. Some parts are nearly identical to plainauth (and I am trying to use this as a source for the user storage backend) and I want to remain compatible to some extent with that. Other bits are cobbled together from stackoverflow and a crash course in self taught PHP, brought up to date from 2018 to today.

As the authentication and identity is external, there's no need for passwords, so while it sets it, it does not do anything with it. If you decide to go back to plainauth then you at least have a current user list and can use some other reset mechanism for that.

• added global $conf and fixed typo in createUser (2024-04-25 16:16)
• Flattened folders and fixed some errors (2024-04-25 14:37)
• Fixed typos and globals (2024-04-25 01:39)
• Tidied up variables (2024-04-25 01:21)
• revert folder structure move (2024-04-24 16:15)
• Changed folder structure to fit in with extension manager reqs (2024-04-24 16:05)
• copy files from original installation "Weatherwax" (2024-04-24 15:58)
• Initial commit (2024-04-24 15:47)

• Detect and use DOKU_CONF directory in defaults (how?)
• Create users file if it doesn't already exits
• Handle email as username
• Create new users

Because the plugin relies heavily on “trustExternal”, new user creation is not possible due to a block in entering the username. To onboard new users, you must either go into the userfile on the backend and pre-populate the necessary information, or require a login first, and then go into the Admin→Users area to set groups after the fact.

Why did you do this - aren't there already good answers for this? Well, not one that suited my use case. I've offloaded authentication (shibboleth) and it sets vars for apache2, and I trust those. I do need to control access, but that's an AuthZ issue, not AuthN. If you can get in, you've already been trusted to come into the walled garden. I do need to put some controls in to make sure that our users can look at the flowers (but not in the potting shed), and the gardeners can do some maintenance while the visitors can't interfere with it.

Who are you? I've been a professional software engineer (e.g. I get paid for this) for over 25 years and mostly keep to myself. I take advantage of OSS, and sometimes I like to give a little something back. I run and maintain several websites (not for profit - blogs etc) when I'm not doing my main job which is less and less about writing code as it is about managing a very large system and teams of developers. Code is less sassy.