> On Aug 31, 2015, at 3:14 AM, Emmanuel Lécharny <[email protected]> wrote: > > Le 30/08/15 16:30, Gerard Gagliano a écrit : >> Hello all, > > Hi Gerard, >> >> We would like to offer the Apache Directory Project a RADIUS server we have >> been working on that is partially functional using a past generation >> FreeRadius dictionary. The software does not yet handle RFC extensions in >> the current FreeRadius dictionary, as well as several other features of >> RADIUS. >> >> The server is configured by reading these dictionary files. It has an >> abstract backend interface and should require very little effort to be >> connected to the Apache Directory Service. >> >> We are not very familiar with LDAP storage schema, so that is the primary >> area where we would expect to need some assistance. >> >> The software cannot be considered ready for use, but with community input >> can be ready quickly. >> >> We will also need guidance on style, format, process and any legal issues >> regarding transfer. >> >> Please advise how can we start the process of submitting this work to the >> Apache Software Foundation. > > A RADIUS server would certainly fits well in the Directory ecosystem, > considering it's dealing with AAA, and that a LDAP directory already > handles teh first 2 As (Authentication and Authorization). The Auditing > part is something that has to be a side component.
Our RADIUS implementation does Authentication/Authorization using an abstract backend as the authoritative information store. Thus we would have all information used by the RADIUS implementation in the ADS (or any other) backend. Deciding how to represent this information in ADS, and the creation of the shim to connect the RADIUS service to ADS is the area where we would appreciate some help. The implementation includes methods for Accounting message logging. > What would be interestig is to have a description of the implemented > features in your implementation (do you have any pointer ?). We will distribute the JavaDoc, which will hopefully answer any questions regarding features. A more complete understanding is RFC attribute type definitions that are not implemented in the code yet. These include 'ether', 'abinary', 'vsa', 'tlv', newer attribute types such as 'extended', vlong-extended', 'evs', 'ifid' and 'EAP' support. > Otherwise, it's pretty simple : we just have to vote the contribution, > assuming we can have a look at the code and existing doco. What is the best means to share this with the community? > Regarding the requirements, it's also pretty simple : > - the code and doco has to be under the Apache License 2.0 > - any external dependency must be under AL 2.0 or under a compatible license > - all the contributors must of course agree to donate the code to The > ASF (license is one thing, copyright is another) > - Style : two options. Either the Directory style > (http://directory.staging.apache.org/apacheds/coding-standards.html) or > the (slightly modified) Java coding style > (http://mina.apache.org/mina-project/developer-guide.html#coding-convention) > - repository : either SVN or GIT. Both are valid SCMs, but I think in > the middle term, we might switch completely to GIT > - issue tracking : we use JIRA. We can migrate any existing JIRA repo to > teh Apache JIRA repo > - IP clearance : we do have to conduct some IP Clearance : > https://incubator.apache.org/ip-clearance/index.html > - name : RADIUS is already in use, so a name has to be found for the > project. This is not the easiest thing (it took weeks before we agreed > on kerby for instance for the Kerberos Server...). Do you have something > in mind ? The only dependency is a dictionary, which is not part of the donation. We have used the FreeRadius dictionary, which is under GPLv2 and not currently Apache License compatible. As for a name, we were thinking Apache Radius. If that doesn’t work (and given the potential for extension into the Diameter world), maybe Apache Radius2x :-), Apache Geometry, or Apache Chord! > otherwise, the key here is 'community'. Ie, we expect that the project > will be maintained in the long run, either by the initial contributors > or by some new contributors. That means we need to advertize the project > so that it attracts new users, and eventually new contributors > (developpers documenters, etc). This is the key part. That would require > an amount of effort from the people bringing the project to The ASF, at > least up to the poijnt we have gained traction : the whole idea is to > make the project being used at large, benefiting from The ASF exposition > to gain some visibility. > > I hope I have replied to your questions, we will be pleased to hear > forward about the RADIUS project ! Please let us know the next steps. > Emmanuel
