Bug 968422

Summary: Feature Request - Implementation of The Standard Standard Interchange Protocol 2.0 as an authentication mechanism option
Product: [Fedora] Fedora Reporter: Timothy M. Butterworth <timothy.m.butterworth>
Component: freeradiusAssignee: Nikolai Kondrashov <nikolai.kondrashov>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: ascheel, dennis, jgrulich, lemenkov, nhosoi, nkinder, rdieter, rmeggins, tcallawa, than, timothy.m.butterworth
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-02 13:12:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
3M SIP2 Published Specification none

Description Timothy M. Butterworth 2013-05-29 17:12:19 UTC
Created attachment 754477 [details]
3M SIP2 Published Specification

Description of problem:
The Standard Interchange Protocol 2.0 is a proprietary standard communication protocol that is developed and published as a standard by 3M. It is primarily implemented to provide communication between Library Computer Systems and Self-Service Circulation Terminals. This protocol is implemented across the majority of Integrated Library Management Systems including open source LMS software such as KOHA.

One of its functions is patron library card “user account” creation and authentication.

In addition to this it is also implemented in envisionware PC Reservation which can utilize to provide patron accessible computers systems with authentication utilizing their existing library cards.

Currently there is no direct integration of The Standard Interchange Protocol 2.0 as an authentication mechanism for Linux. Although it may be possible to to utilize RADIUS authentication with The Radiator RADIUS server to proxy from RADIUS to SIP2. Radiator is the only RADIUS product I have currently found so far that supports SIP2. OSC Radiator SIP2 Announcement: http://www.open.com.au/pipermail/radiator/2012-July/018433.html 


Use Case
Incorporating SIP2 as an authentication mechanism in Linux Distributions would provide a means for libraries to Integrate Linux systems for patron internet access utilizing their existing LMS Patron user accounts. This opens up an additional sales market.

The majority of libraries currently have and others are planning to implement patron internet access systems. This is beneficial for Red Hat as Red Hat Enterprise Desktop could be purchased and deployed instead of the more costly solution which currently requires Envisionware PC Reservation licenses, Microsoft Windows Licenses as well as additional software licenses costs.


Implementation
As many open source software projects such as Koha have already implemented SIP2.0 and their source code is available under various open source licenses that code base could be utilized as a model or reused to implement this authentication. The Source code is also available for review in the commercial OCS Radiator Product as well.

Also the entire SIP 2.0 specification would not need to be implemented just the client logon component.

Which incorporates the following behavior:
 
Formatting and sending SIP2 Patron Status Request message (type 23) with Patron's identifier and password to the specified SIP2 server. 

Receiving and processing SIP2 Patron Status Response (type 24) from the SIP2 Server.

This would allow the basic authentication to take place.

This could also be incorporated into a domain authentication system such as Fedora Directory Server to provide more advanced user management such as user logon restrictions such as authorized logon times and maximum session duration if a component was implemented to create a trust for the external SIP2 patron accounts.

Comment 1 Rex Dieter 2013-05-29 17:29:24 UTC
The "sip" component here in bugzilla is all about
http://www.riverbankcomputing.com/software/sip/intro

I've no idea where best to triage this (if at all), try general 'distribution' for now.

Comment 2 Bill Nottingham 2013-05-29 17:41:58 UTC
Any of the open source components you mention could be packaged for Fedora at any time, assuming they're of an appropriate license. If you're interested in doing so, see:
  https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

That being said, integration of authentication methods/user databases may be more appropriate for the directory server, as you mention. Moving to fedora-ds.

Comment 3 Rich Megginson 2013-05-29 17:46:46 UTC
This seems possibly pam or radius related

Comment 4 John Dennis 2013-05-29 18:47:23 UTC
There are probably a number of ways handling this authentication service could be handled, that's a technical issue with technical solutions. What I don't understand is what this feature request is all about, it's filed against Fedora, an open source community distribution. We're not in the business of doing custom software solutions on a volunteer basis. This is open source, if you want a feature then the usual mantra applies "patches welcome". Or if there is existing open source solutions but they just need to be packaged for Fedora then why not package them?

There are 3 steps involved:

1) Figure how you want to solve the authentication problem. We can probably provide guidance but realize we also have many other things on our plates.

2) Find someone to implement it.

3) Get it approved/reviewed.

Am I missing something here?

Comment 5 Kevin Kofler 2013-05-29 22:58:36 UTC
Have we reached the record number of reassignments yet? ;-)

In any case, this does not affect anything I maintain, so I'm unCCing myself, sorry.

Comment 6 Timothy M. Butterworth 2013-05-30 21:22:38 UTC
Is it possible to have this transferred as a feature request for Red Hat Enterprise Desktop?

Also I currently already checked with FreeRADIUS and according to the response I received back they were not interested in taking on implementing it at this time.

I do not think that is would be possible to simply package the components from Koha or other components as is. As implementing it would require a mean to define it as a logon mechanism to the desktop.

Implementing it through a directory server would likely take less work I would think.

I personally do not have the programming skills to implement this so I am currently looking for a company to implement it in a solution that will work so we can just purchase a product that already incorporates it to reduce our current costs.

200+ Windows PC, Envisionware PC Reservations licensing costs, MS Office Licensing Costs spread across two library locations. As well as other windows security product licensing costs.

I will be testing The OCS Radiator Product here later this year to provide Patron access authentication to a wireless guest network. Currently I have not found any wireless/Captive Portal software that has native support for SIP2 either.

If that works out I may look at implementing a RADIUS forwarding login method with Linux through OCS Radiator as well. I would rather have something that is more integrated than using RADIUS proxy though.

SIP2 is currently integrated throughout all of our patron access systems: Public Access Computers, Self service check out, Materials reservations etc. I know there is a sales market here in the library user space as the majority of libraries across the world utilize SIP2 just as we do.

Comment 7 Rich Megginson 2013-05-30 22:10:06 UTC
(In reply to Timothy M. Butterworth from comment #6)
> Is it possible to have this transferred as a feature request for Red Hat
> Enterprise Desktop?
> 
> Also I currently already checked with FreeRADIUS and according to the
> response I received back they were not interested in taking on implementing
> it at this time.
> 
> I do not think that is would be possible to simply package the components
> from Koha or other components as is. As implementing it would require a mean
> to define it as a logon mechanism to the desktop.
> 
> Implementing it through a directory server would likely take less work I
> would think.

It could go into a directory server, but
1) that would limit it's application to only LDAP authentication
2) it would have to be a proposed IETF standard LDAP/SASL authentication mechanism

> 
> I personally do not have the programming skills to implement this so I am
> currently looking for a company to implement it in a solution that will work
> so we can just purchase a product that already incorporates it to reduce our
> current costs.
> 
> 200+ Windows PC, Envisionware PC Reservations licensing costs, MS Office
> Licensing Costs spread across two library locations. As well as other
> windows security product licensing costs.
> 
> I will be testing The OCS Radiator Product here later this year to provide
> Patron access authentication to a wireless guest network. Currently I have
> not found any wireless/Captive Portal software that has native support for
> SIP2 either.
> 
> If that works out I may look at implementing a RADIUS forwarding login
> method with Linux through OCS Radiator as well. I would rather have
> something that is more integrated than using RADIUS proxy though.
> 
> SIP2 is currently integrated throughout all of our patron access systems:
> Public Access Computers, Self service check out, Materials reservations etc.
> I know there is a sales market here in the library user space as the
> majority of libraries across the world utilize SIP2 just as we do.

Comment 8 Timothy M. Butterworth 2013-05-30 22:55:59 UTC
I will look into submitting Internet Drafts to IETF to implement this in LDAP as well as a RADIUS Extension.

Comment 9 Timothy M. Butterworth 2013-05-30 23:01:34 UTC
Also their is currently work taking place on a ANSI standard to replace SIP2. As this is the proposed future replacement I am not sure if it currently includes as specifications with LDAP or RADIUS so I will take a look into it as well.

The National Information Standards Organization Circulation Interchange Protocol (NCIP) is a protocol that is limited to the exchange of messages between and among computer-based applications to enable them to perform functions necessary to lend and borrow items, to provide controlled access to electronic resources, and to facilitate cooperative management of these functions.

Released in May 2001 and approved on October 17, 2002, ANSI/NISO Z39.83-2002 or NCIP is a "NISO Draft Standard for Trial Use." This protocol defines a repertoire of messages and associated rules of syntax and semantics for use by applications: to perform the functions necessary to lend items; to provide controlled access to electronic resources; and to facilitate co-operative management of these functions. It is intended to address conditions in which the application or applications that initiate the lending of items or control of access must acquire or transmit information about the user, items, and/or access that is essential to successful conclusion of the function.

Comment 10 Fedora Admin XMLRPC Client 2014-07-02 17:25:03 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Alex Scheel 2019-10-02 13:12:02 UTC
This is outside the scope of the upstream project: https://github.com/FreeRADIUS/freeradius-server/issues/287