Bug 21586

Created attachment 80689 [details] [review]
Bug 21586: Add generic OpenIDConnect client implementation

BEWARE: This patch is not ready sign off!

This is partially since it exists within Prosentient namespaces,
and partially because a lot of things could probably be improved,
since I originally wrote this code 4 years ago for 1 specific
client.

I'm adding this patch so that others can look at this work,
and either adapt it themselves, or test it and give me feedback
so that I can update it.

I can't guarantee that it works in its current state, as the latest
version I support with this code is 17.05, and I've touched up
a few things here and there that differ from my running code.

To test:
1) View the =head1 DESCRIPTION in opac/svc/login_openidc. It tells you to write a large chunk of XML into koha-conf.xml. (NOTE: The "prosentient" element is a subling to the "config" element. The only parent to the "prosentient" element is the "yazgfs" element. This is very important.)

2) Configure koha-conf.xml to point to the OpenIDConnect server to which you want to connect. 

3) Change $debugging in opac/svc/login_openidc from 0 to 1. This will help you with your troubleshooting considerably.

4) On your Koha OPAC, using a system preference, add a URL like http://your-koha-host/cgi-bin/koha/svc/login_openidc?pid=foo

5) Click on that link and it should redirect you to a login page for your upstream authentication provider. After you fill that you, you should be returned to your Koha as a logged in user (NOTE: email address is used for matching... if your email address already exists in Koha, you'll be logged in as that user. If your email address doesn't exist, a new user will be created with your details from your upstream provider.)

--

If I've missed anything, comment here or reach me on IRC, and I can provide more details!

login_openidc is a bit outdated with its POD...

Additional configuration options to consider as children of the "provider" element:

<client_authentication_method>client_secret_post</client_authentication_method>
<bearer_access_token_method>form</bearer_access_token_method>
<logout_url>https://provider/openidconnect/destroy_session</logout_url>

Another optional child of the "mapping" element:

<koha_sort1>company_name</koha_sort1>

(I added this since OpenIDConnect technically allows providers to provide non-typical claims too. This could use a better mechanism for configuration.)

Comment on attachment 80689 [details] [review]
Bug 21586: Add generic OpenIDConnect client implementation

Review of attachment 80689 [details] [review]:
-----------------------------------------------------------------

::: C4/Auth.pm
@@ +1789,4 @@
>      }
>      else {
>          # catch all defaults to tmp should work on all systems
> +        my $dir = C4::Context::temporary_directory();

Ooops. This was a local fix that I did so that C4::Auth would compile for my client side git hook...I should take that out.

I've recently been looking at Keycloak https://www.keycloak.org and I'm thinking it could be something that we use for testing this.

Happy for other people to work on this. This isn't really a priority for me at the moment, although it would be a great addition to Koha!

*** Bug 3237 has been marked as a duplicate of this bug. ***

This code is out of date, and has a few known problems. However, I have a newer version, which I actually have working with the Keycloak OpenID Connect Identity Provider.

For testing purposes, I very easily ran up an instance in Docker (https://hub.docker.com/r/jboss/keycloak/), and after resolving a bug in my code, I was able to successfully authenticate and auto-add a patron to Koha. 

It's worth noting that I have used Keycloak for other projects for a while now, so the server configuration was trivial for me, but it might not be obvious at a glance. There is lots of documentation though. 

Might also be worth noting that Keycloak is sponsored by Red Hat and forms the core of RH-SSO, which Red Hat actually uses for all its own AuthN purposes. 

Note that even though I have a new version of the code that works, I'd actually like to redo my code for this one.

Actually, this one would be great to add as an "Authentication Plugin" for Koha. 

Looking at my code, the only part of it which doesn't lend itself to a plugin architecture are the changes to Auth.pm and opac-auth.tt. 

However, we could probably remove the necessity for opac-auth.tt changes.

And we could add hooks into Auth.pm for login and logout. Looking at my code, those shouldn't be that hard to add. 

--

One of the interesting things with this work was setting up multiple OpenID Connect providers. I'm not sure how often that would actually be a requirement (as I think people sometimes use another IdP to federate others together) but it was originally a requirement for my work, and it's something I've seen other people ask for online. 

--

Really we should be able to use OpenID Connect against Google and any other compliant IdP (like Keycloak).

I don't have plans to work on this at present, but it is an interest of mine, so if I find myself with spare time, I would work on it (although the OAI-PMH harvester is a competing albeit much more complex interest).

Created attachment 97684 [details]
Local login plus external login

Example of local login plus external logins.

The links/buttons are for URLs like this:

https://gitlab.com/users/auth/google_oauth2
https://gitlab.com/users/auth/twitter

It would be interesting to have plugins so that we could do things like:

https://koha/users/auth/google
https://koha/users/auth/custom_idp1
https://koha/users/auth/custom_idp2

I decided to make some strides on generic authentication and opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24539

I've refactored my OpenID Connect code to take advantage of a standard generic interface in Auth.pm and opac-auth.tt. 

I still have some work to do on the endpoint that triggers the login, but I have some ideas about that.

Great news, David.

*** This bug has been marked as a duplicate of bug 30988 ***

While this patch has more functionality than bug 30988, it was originally written for a buggy OIDC IdP 8 years ago and it's outdated in a number of ways. 

While I run a newer local version in prod (and I probably will keep running it locally), I actually want to re-write this functionality using Mojolicious. In fact, there's already a plugin to take care of the majority of it: https://metacpan.org/pod/Mojolicious::Plugin::OAuth2

But I'm not planning on doing that any time soon, so I'm happy to endorse bug 30988 as the replacement for bug 21586, since Shi Yao Wang is actively working on that one.

Just noting that I've signed off Bug 30988 so it would be great to get some QA eyes on it.