Open jfmartinezm opened 1 year ago
Do you have any specific APIs/Documentation to work from for specific ILSs?
I would have no problem integrating different authentication schemes under the Libki::Auth namespace with some re-engineering of Libki::Auth to make it a bit more generic than it currently is for LDAP if needed and/or possible.
As far as I know there's no formal API Documentation for the interaction with the ILS we are using, as that authentication interface was custom-built for another app (we just took advantage of it to integrate our current management system). But this is, more or less, how it works in this case:
{
"error": 0, // 0 if correct, other value if error, rest of the fields won't appear in that case
"email": "john@email.com",
"name": "JOHN",
"suspended": 0,
"expired": 0,
"type": "ADULT",
"library": "MAIN",
"branch": "1"
}
To make the authentication module somewhat generic, it could use configuration values specifying the names for the fields on the request and the response, if any of them are required to exist and/or have a certain value, and how to map them to Libki fields.
Has there been work started on a generic HTTP interface? I'm seeing some potential for integration with a custom authentication service and may be able to contribute to this effort.
Does the HTTP endpoint return specific codes (200, 403, etc) or only 200 with the JSON record that has to be parsed to determine success/failure?
For the use case I have, it would be to integrate with a custom authentication system that's under my control as the primary developer.
I'd envision a simple HTTP interface within Libki auth that: (1) sends an HTTP POST with JSON containing the patron submitted username/password, barcode/pin, or similar to an endpoint on the custom authentication system, (2) the custom auth system does any heavy lifting to communicate with the target ILS to verify the patron credentials, and (3) custom authentication system returns an HTTP status code at minimum.
Certain ILS implementations don't allow full integration over standard protocols, like SIP2 or LDAP. It could be useful if that integration could be achieved through some kind of HTTP interface.
It could be implemented on a separated authentication module, similar to the current implementation for SIP and LDAP. The details would depend on the particular implementation, but the module could be configured to allow different ways of sending and receiving the information (HTTP POST fields, JSON format, etc).