You've got me there, I wasn't even thinking about third-party services like OAI-PMH. My comment about avoiding auth is only really feasible for first-party or locally developed cli scripts. (I could say second-party there, but that's just silly.) Third-party services definitely need to authen, and probably authiz too. A message broker would be handy for that, where you probably have one set of credentials that are shared by any services talking on that queue. oAuth can do that too, but you'd have to build a way for the client id and secret to be stored by both services in lieu of a username and password. Which seems basically the same to me as having a username and password. On the one hand we'd have to build a connector between the message broker and the Koha api's. On the other hand we'd have to build oAuth access token handling into the existing api's. (where the appropriate api's already exist.)
On Sun, Aug 9, 2020 at 7:00 PM <dc...@prosentient.com.au> wrote: > Hi Michael, > > > > Another case where a Koha to Koha API would be useful is in the use of > additional service (or microservices). At the moment, the SIP server is > closely coupled with Koha, but it could just as easily be a separate > component that used HTTP APIs (rather than internal Perl APIs) to work with > Koha. > > > > You could argue that you could avoid auth (although I don’t understand > your interpretation of MCV in this case), but that would be out of > convenience rather than security. You could argue that you just protect the > edges of your host (via a firewall for instance), but what about if that > service isn’t running on the same host? Then you need to open a hole in > that firewall. Then how do you protect that hole? Just using IP addresses > isn’t going to work very well. You’ll want to have authentication and > authorization, especially when your application is part of a larger > multi-vendor cloud ecosystem for instance. > > > > The particular use case I have in mind is for a OAI-PMH harvester service. > There could be 1 OAI-PMH harvester servicing many Koha instances. It could > be running in its own local Docker container or its own local virtual > machine or even as a remote Internet service controlled by a different > organisation. It’s only relation to Koha is in terms of accepting JSON > serialized harvesting requests and sending MARCXML records for Koha to > import. > > > > For integrating the services, we could use point-to-point (P2P) > communication via the HTTP APIs. That’s pretty much the only option we have > at the moment. However, Koha will be adding RabbitMQ as a Message Broker > (for a hub-and-spoke model), so Koha and the other services could have > their own credentials to authenticate against the Message Broker, and use > it for communication. Both models have their pros and cons. > > > > My current plan is to use > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170 to > provide more stable Koha users and > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25905 to > provide an OAI-PMH ingestion endpoint to Koha. Then I’ll implement the > OAI-PMH harvester separate from Koha (with a Koha plugin initially to send > OAI-PMH harvesting requests to the OAI-PMH harvester service), which sends > downloaded records to the Koha API for the Koha that requested the harvest. > This approach will have some friction though. I’ll have to add a Koha user, > share the Koha user credentials to the OAI-PMH service, register the Koha > instance in the OAI-PMH service, and share the OAI-PMH credentials with > Koha. That process could be unnecessary using a Message Broker. Another > option would be to set up single sign on (SSO) with P2P where Koha and the > OAI-PMH service delegate AuthN (and even potentially AuthZ) to an identity > provider. That would make things smoother but also more complicated. > > > > If I wanted to more tightly integrate with Koha, I suppose I could create > a koha-oaipmh CLI tool which automates the user creation and credential > sharing I suppose. > > > > The other benefit of using the Message Broker is that you don’t have to > manage IP addresses and ports. I should look at the koha-sip tool again, > but I don’t know how it handles setting up different ports for each > different Koha instance. > > > > In any case, I’m keen to get input from others on system design. On one > hand, I’d like something that easily works for everyone, and on the other > hand I’d like something that works really well. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > *From:* Michael Hafen (TECH) <michael.ha...@washk12.org> > *Sent:* Saturday, 8 August 2020 2:46 AM > *To:* David Cook <dc...@prosentient.com.au> > *Cc:* Koha Devel <koha-devel@lists.koha-community.org>; Kyle Hall < > k...@bywatersolutions.com>; Tomas Cohen Arazi <tomasco...@theke.io> > *Subject:* Re: [Koha-devel] Best practices for using Koha APIs > server-side by Koha > > > > Maybe I'm lacking in imagination, but I can only think of two cases where > a Koha to Koha api would be useful: scheduled tasks (cron, et. all), and > command line scripts. I think in both of these cases it's feasible to > avoid auth entirely since it is basically jumping right into Koha at the > control level (assuming an MCV approach). As someone who has a deployment > of Koha heavily dependent on IndependentBranches mode, I find I have to > watch for %userenv{branch}, but that's for rare cases in which branch can't > be taken from the data being operated on. The only other thing I can think > of would be something like notices wanting to take a user's preferred > language, and pull a language specific template (do we even do that at this > point?). > > Please enlighten me on your use cases, I'm probably missing something. > > > > > > On Fri, Aug 7, 2020 at 5:09 AM <dc...@prosentient.com.au> wrote: > > Hi all, > > > > I mostly see Koha APIs being used client-side by Koha using cookie > authentication. > > > > I know we have OAuth2 and Basic Auth that can be tied to a Koha user, and > used by a third-party system, which is great. > > > > However, what about when we have server-side Koha components that want to > use Koha APIs? (I suppose you could set up a user for that component, but > it could always be deleted by an overzealous librarian.) > > > > Or should we only be using a Message Broker (like RabbitMQ) for passing > messages among Koha server-side components? (That would require more of a > service oriented architecture of course, which we don’t have in place, > while we do have a HTTP API in place.) > > > > What are your thoughts? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Online: 02 8005 0595 > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > https://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/ > > > > -- > > Michael Hafen > > Washington County School District Technology Department > > Systems Analyst > -- Michael Hafen Washington County School District Technology Department Systems Analyst
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://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/
