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: | freeradius | Assignee: | Nikolai Kondrashov <nikolai.kondrashov> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | 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
Timothy M. Butterworth
2013-05-29 17:12:19 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. 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. This seems possibly pam or radius related 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? 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. 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. (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. I will look into submitting Internet Drafts to IETF to implement this in LDAP as well as a RADIUS Extension. 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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This is outside the scope of the upstream project: https://github.com/FreeRADIUS/freeradius-server/issues/287 |