Developing an Implicit Auth plugin for OpenID Connect providers

Software Support
1

I’m currently setting up SSO for an OJS installation using an OpenID Connect (OIDC) Identity Provider.

At the moment I have a proof of concept working, but this is implemented by manually editing the LoginHandler class rather than by implementing an ImplicitAuthPlugin.

I’m thinking about writing this as an ImplicitAuthPlugin that can be shared back to the OJS community but there are a couple of small issues:

  • There is a bit of code in the PKPLoginHandler::implicitAuthLogin method that is Shibboleth-specific and cannot be overriden via a plugin. Namely, the format of the redirect URL that sends the user to the login screen of the Identity Provider is hardcoded. I propose adding an extra hook e.g. called ImplicitAuthPlugin::implicitAuthRedirect that allows an ImplicitAuthPlugin to perform the redirect itself (or do nothing, in which the current behaviour continues - so this is backward compatible.)
  • Currently the implicit_auth setting in the config file is a boolean on/off option. Using an non-Shibboleth implicit auth plugin requires disabling the existing Shibboleth plugin by manually editing the code. It would be nicer if there was some way to select between plugins - perhaps the implicit_auth setting could be a string setting instead, with values like ‘shibboleth’, ‘oidc’, ‘cas’? Plugins would only register for hooks if the implicit_auth setting matched a particular value (not sure about backward compatibility here)

(Disclaimer: I’ve only been working with OJS for a few days)

Some questions:

  • Is anyone interested in this plugin?
  • Any objections to adding the extra hook for generating the redirect to an Identity Provider?
  • What about changing the implicit_auth config setting from a boolean to a string?
2

Hi @ammojamo,

The implicit auth plugin category was a third-party contribution made with the intention of supporting Shibboleth and hasn’t been groomed for other uses, although that was its goal. @ctgraham will probably have some comments on this as well. I’d suggest adjusting as you propose, with some thought to backwards compatibility – a true for implicit_auth, for example, could be coded to behave like shibboleth in the new structure you propose. Let me know if you get stuck or would like some guidance!

Regards,
Alec Smecher
Public Knowledge Project Team

3

+1 here.

I would be happy to review a Github pull request for something like this.