[Bug 25796] New: Allow REST API to use external OAuth2 authorization server
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 Bug ID: 25796 Summary: Allow REST API to use external OAuth2 authorization server Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs@lists.koha-community.org Reporter: dcook@prosentient.com.au At the moment, Koha's REST API only validates tokens using the embedded authorization server Net::OAuth2::AuthorizationServer. It would be great if Koha were configured to use an external authorization server (like Keycloak). We could redirect the /token endpoint to Keycloak, or just require consumers to query Keycloak directly for access tokens I suppose. Then we'd set up Koha to either embed (or more sustainably fetch) Keycloak's public key in order to verify that the access token is coming from Keycloak. We'd then do further token validation (to make sure it's not expired, it's for the correct audience, etc). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=20402 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- One of the advantages of using an external server like Keycloak would also be that the API would be able to be used with many different grant types and not just client credentials. At some point, I'm planning to upstream some work I've done on integrating Keycloak (and any other compliant OpenID Connect Identity Provider) via Bug 21586 for regular end user login. For what it's worth, this is a setup I've worked on with other projects. There will be a central identity provider, which can also include authorization information, and all the organisation's applications will use that same central IdP to issues tokens, and then all the applications are configured to consume those signed (JWT) tokens. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=21586 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 claire.hernandez@biblibre.com <claire.hernandez@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |claire.hernandez@biblibre.c | |om -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com Depends on| |30194 Assignee|koha-bugs@lists.koha-commun |tomascohen@gmail.com |ity.org | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30194 [Bug 30194] Adapt Koha for JSON::Validator@5.x -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 Bug 25796 depends on bug 30194, which changed state. Bug 30194 Summary: Update required JSON::Validator version https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30194 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Here's another thought: If Koha and other applications used Keycloak for SSO, the id_token and refresh token could be saved, and used beyond the initial login. For instance, a user logs into MyApp, which redirects them to Keycloak and back to MyApp. They click "Place a Hold" on an item in MyApp, which then sends an API request with id_token to Koha. Koha takes the id_token and validates it against Keycloak. If it's valid, API request proceeds. If it's invalid, it spits out a 401. MyApp could verify the id_token ahead of time or re-try after using the refresh token to get a new id_token. That's irrelevant right now. -- The only difficulty I have in mind at the moment is... how does Koha know which IdP to query with the id_token? It's easy if your Koha is only set up with one IdP. With more than one, it would be more complicated... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- Unless the Keycloak uses Koha as its backend user storage, I suppose that could circumvent a number of Koha business rules though. That would need to be checked. Hmm this is interesting: https://developers.google.com/identity/sign-in/web/backend-auth In that example, you get the id_token from your SSO IdP, and then you send it to your other backend server (eg. Koha), and then Koha can verify the token (at this point it can create a new user if one is missing, or it can validate an existing user). Then Koha could return whatever. Hmm needs more thought. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- But then if you read this: https://auth0.com/blog/id-token-access-token-what-is-the-difference/ In theory, the access token should be for the "Resource server" (ie the Koha API). I suppose that the access token can then be used to do a UserInfo lookup in order to get the user info (I did that in my early 2014 OpenID Connect work). I suppose the Koha API would check the "iss" and "aud" claims. The "iss" would let it know what IdP to talk to (and whether or not it trusts it). I think the "aud" would need to be the whole Koha API and then further authorization would be handled by Koha at a more granular level... Looking at Koha::OAuth, it would be fairly trivial to add support. We'd just need a table really to store providers. If the "iss" provider isn't found in the table, then we default to a Koha supplied access token. We need a table to store providers anyway for improving Koha's SSO options so this dovetail with that. If we wanted to handle this with plugins, we could do that instead so long as we put a plugin hook in "Koha::OAuth::_verify_access_token_cb". It does look like we'd need to alter Koha::Rest::V1::Auth a little bit as it tries to lookup the patron using the "client_id" in the access token. Anyway, lots of possibilities there. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- I might actually end up doing this work locally. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 Sven <sven+koha@geeq.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sven+koha@geeq.de -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #6 from Sven <sven+koha@geeq.de> --- Alternatively, it would be possible to support the integration of Apache2 mod_auth_openidc (https://github.com/OpenIDC/mod_auth_openidc) similar to Shibboleth (https://wiki.koha-community.org/wiki/Shibboleth_Configuration). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25795 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41671 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- Let's say you're in an ecosystem where you have 1 IdP shared across many apps (all with their own OIDC clients). The end user logs into the Discovery System (DS) using IdP OIDC SSO. It then performs token exchange with the IdP to request an access token for Koha. It then sends that access token to Koha. Koha validates that token (ideally a JWT) using IdP details, performs auth, and then returns the API results. This should actually be pretty easy to do. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- With https://gitlab.com/minusdavid/keycloak-user-storage-koha I created a Keycloak extension to allow Keycloak to be the OIDC layer and Koha to be the user storage backend. But thinking about it again... another approach would be to have Koha provide an LDAP server, as Keycloak, Dex, and other IdPs allow for federation using LDAP(S). At some point, we'll need to talk about SCIM (System for Cross-domain Identity Management) as well... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25796 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42942 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org