Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: A Java RADIUS Server
To: dev@directory.apache.org
References: <21F30BE2-4DBA-4A81-896D-5F024D5F6B86@prodentity.com>
From: =?UTF-8?Q?Emmanuel_L=c3=a9charny?= <elecharny@gmail.com>
Message-ID: <55E41AE8.3060300@gmail.com>
Date: Mon, 31 Aug 2015 11:14:16 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <21F30BE2-4DBA-4A81-896D-5F024D5F6B86@prodentity.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Le 30/08/15 16:30, Gerard Gagliano a =C3=A9crit :
> 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 o=
f RADIUS.
>
> The server is configured by reading these dictionary files.  It has an =
abstract backend interface and should require very little effort to be co=
nnected to the Apache Directory Service.
>
> We are not very familiar with LDAP storage schema, so that is the prima=
ry area where we would expect to need some assistance.
>
> The software cannot be considered ready for use, but with community inp=
ut can be ready quickly.
>
> We will also need guidance on style, format, process and any legal issu=
es regarding transfer.
>
> Please advise how can we start the process of submitting this work to t=
he 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.
What would be interestig is to have a description of the implemented
features in your implementation (do you have any pointer ?).

Otherwise, it's pretty simple : we just have to vote the contribution,
assuming we can have a look at the code and existing doco. 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 lice=
nse
- 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-conventi=
on)
- 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 ?

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 !

Emmanuel