<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Hi all,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ve been thinking a little about API security. When I look at <a href="http://localhost:8081/api/v1/.html">http://localhost:8081/api/v1/.html</a>, I see every API route we define in Koha. Do we really want all of these APIs to be accessible to any API consumer?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In many cases, I imagine we only want Staff Interface users (or approved third-party tools) using a lot of these API routes. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>At the moment, if someone cracks the password of an admin user on the OPAC, they’d then be able to access admin APIs via the OPAC site. That seems suboptimal to me. In theory, breaching the OPAC should have a small blast radius that only affects one user. In practice, if someone breaches the OPAC with an admin user, the blast radius can still be large.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Based on <a href="https://www.keycloak.org/docs/latest/server_admin/index.html#admin-endpoints-and-console">https://www.keycloak.org/docs/latest/server_admin/index.html#admin-endpoints-and-console</a>, it could be good to have separate admin API and public API interfaces, which can then be configured and protected differently. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I suppose a person could IP restrict the API at the moment and just allow public access to /api/v1/public/ routes. I suppose I just wonder about having more restrictive defaults, although in the Keycloak case the defaults are permissive…<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Anyway, just sharing my thoughts on this one. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>David Cook<o:p></o:p></p><p class=MsoNormal>Software Engineer<o:p></o:p></p><p class=MsoNormal>Prosentient Systems<o:p></o:p></p><p class=MsoNormal>72/330 Wattle St<o:p></o:p></p><p class=MsoNormal>Ultimo, NSW 2007<o:p></o:p></p><p class=MsoNormal>Australia<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Office: 02 9212 0899<o:p></o:p></p><p class=MsoNormal>Online: 02 8005 0595<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>