Generic OpenIDConnect client

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Generic OpenIDConnect client

dcook

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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Generic OpenIDConnect client

Tomas Cohen Arazi
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 (<[hidden email]>) 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
[hidden email]
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)
✆ +54 9351 3513384
GPG: B2F3C15F

_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Generic OpenIDConnect client

Mark Tompsett
Greetings,
 
tcohen wrote in response to dcook’s request for feedback:
> - I had the feeling this should be done with plugins.
> Because every implementation has its details that make them less compatible with the other.
 
I concur with this idea.

Tangentially, it would also make refactoring authentication easier.
Right now, certain combinations of authentication work in a particular order, and there is no way to change that.
Plugins would let us access them in a particular order, and even configure them IN the staff client, not just
koha-conf.xml which gets filled pretty quickly with authentication cruft (ldap, shibboleth, cas, etc.)
 
GPML,
Mark Tompsett

_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Generic OpenIDConnect client

Tomas Cohen Arazi
We would still need to refactor and modularize auth

El mié., 17 de oct. de 2018 12:00, Mark Tompsett <[hidden email]> escribió:
Greetings,
 
tcohen wrote in response to dcook’s request for feedback:
> - I had the feeling this should be done with plugins.
> Because every implementation has its details that make them less compatible with the other.
 
I concur with this idea.

Tangentially, it would also make refactoring authentication easier.
Right now, certain combinations of authentication work in a particular order, and there is no way to change that.
Plugins would let us access them in a particular order, and even configure them IN the staff client, not just
koha-conf.xml which gets filled pretty quickly with authentication cruft (ldap, shibboleth, cas, etc.)
 
GPML,
Mark Tompsett
_______________________________________________
Koha-devel mailing list
[hidden email]
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/

_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Generic OpenIDConnect client

dcook
In reply to this post by Tomas Cohen Arazi

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:[hidden email]]
Sent: Thursday, 18 October 2018 12:49 AM
To: David Cook <[hidden email]>
Cc: koha-devel <[hidden email]>
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 (<[hidden email]>) 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
[hidden email]
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)
+54 9351 3513384
GPG: B2F3C15F


_______________________________________________
Koha-devel mailing list
[hidden email]
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/