[Koha-devel] Generic OpenIDConnect client

[David Cook]

Thanks for your feedback, Tomas! Apologies for my delay in responding.

 

I hadn’t thought about making it so that web users could configure providers… but that could be interesting. 

 

I think that’s a good point with the plugins. Even with the 3 providers with which I integrate, I notice implementation differences. Some of them legitimate and some illegitimate according to the OpenIDConnect specification. 

 

I really like the idea of refactoring and modularizing auth. I think maybe my patch actually shows that it shouldn’t be that hard to create hooks for authentication plugins. 

 

I’m swamped at the moment (like usual) but it would be fun/interesting to try…

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com] 
Sent: Thursday, 18 October 2018 12:49 AM
To: David Cook <dcook at prosentient.com.au>
Cc: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Generic OpenIDConnect client

 

David, it is nice to see your code submitted!

 

I implemented a generic prototype too, based on the current code for Google's. At that point the doubts I had were about how to inject new routes for the callback. But that's solved the way we did in bug 21116.

 

I didn't submit my prototype because:

- I wasn't able to inject routes (yet)

- A page for CRUD operations on OAuth providers needs to be implemented

- An attribute mapping UI needs to be added for each OAuth provider

- I had the feeling this should be done with plugins. Because every implementation has its details that make them less compatible with the other.

 

This are my thoughts on the subject as well!

 

 

El mié., 17 oct. 2018 a las 6:07, David Cook (<dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >) escribió:

Hi all,

 

About 4 years ago, I wrote a generic OpenIDConnect client, and kept telling myself that I would upstream it but I never did… until now: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21586. 

 

I wrote it for 1 specific client, so it exists heavily in a set of “Prosentient” namespaces and some of the code is legacy from 3.14 and could be replaced by modern code (I’m looking at you Koha::Prosentient::Borrowers), but maybe people can try it out and give me some feedback to make it worthy of a sign off, or people can adapt it and I can give feedback. (I already have some things I would like to change. I think I overuse base64url… but it is essential when working with JWTs. I think I just got carried away with a substitution command once.)

 

I know we already have the GoogleOpenIdConnect. I actually wrote this code before that code existed, but I don’t think my code would work for Google the way it is now. It would probably need some alterations. 

 

Anyway, I was sick of telling myself that I would upstream it one day, so I sat down and made a patch and now it’s shared. 

 

Cheers,

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/




 

-- 

Tomás Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20181024/17ff3a35/attachment-0001.html>