Niklas,
The jsecurity.org is very nice, it's that type of framework that I was
thinking about for making the User "less" or more abstract. This is far
superior though to what I had in mind.
The multiple Realm(s), Authentication, Authorization and especially the
way the Session is handled is nice. I can see where you could
immediately enhance it by adding compliance checks among other things.
The nice thing is it [security] can be completely outside of the file
system, but available to it.
This has some dependencies on the asm-xxx libraries, watch out for these
with Hibernate, and Open-Ejb. If you get class not found errors, pull
down the asm-all-version jar and use it instead of the 3-4 asm jar files
currently used. I had already dumped the home-grown User and replaced
it with a more abstract one, one of the interfaces was with Hibernate,
along with Open-Ejb, the asm stuff was a slight annoyance sorting out.
---
Might be best to make the "security" a separate package, removing the
old User and replacing it with the Subject. The Realm and all the other
components stay outside of the core ftp server that way.
Perhaps start a new project/package
ftp-security
with the base class of:
org.apache.ftpserver.security
to handle the Realms, configuration, and other related matters.
FileSystemManager interface would change to be:
FileSystemView createFileSystemView(Subject subject) throws FTPException
The above is likely one of the most important changes. Most of the
others are really attributes or permissions and can be attached to the
user-session.
The User and UserManager can be removed completely from the code. No
user reference would be needed for FtpSession{*}, so User does not need
to be replaced with Subject there. The PASS, USER, SITE_WHO command can
access the Subject via the SecurityUtils call. The UserMetadata could
go away, move the CertificateChain into the user session using
AuthenticationToken [... or maybe not ...].
{*} -- unless people don't like the singleton access, but then this
would start to tie the user stuff back into the core code. Core code
should focus on transport and actions, not authc/authz, doing certs and
managing users.
All the other odd-ball things like max idle time are moved into the user
session using the session.setAttribute( key, value) as these are both
Objects.
All of the classes in org.apache.ftpserver.usermanager can go away. The
Concurrent, write, and other classes are re-coded to match the jsecurity
versions of them [authz]. subject.isPermitted(Permission ) ie,
Permission ConcurrentLogin ...
They use "authc" package names to designate "authentication" and "authz"
package names to designate "authorization". Just noting this, makes it
easier to scan down or through when looking for something.
I can take a first pass at this since I already ripped out the existing
User/Manager code. I would also like to use this, the faster it's
implemented and tested the better.
---
I think I saw a kitchen sink or two in the code too, looks like they did
not miss much. If it's not supported directly, it's easy enough to add
it. I see they forgot the free beer, oh wait, we're suppose to give that
to them for the nice security package :-).
Andy
Niklas Gustavsson wrote:
On Tue, Jun 3, 2008 at 10:55 PM, Andy Thomson <[EMAIL PROTECTED]> wrote:
Niklas,
What do you think about making User more basic, ie, more abstract, having
only one method such as getEnabled(). Then push everything else up higher,
like the Authority[]. This way we can allow other User-code styles that may
not use the those mappings or approaches. In other words keep the interface
very basic.
Not to detract from this discussion, but my plan is to propose that we
rip out our home-grown security design and replace it with JSecurity
(http://www.jsecurity.org). The project is currently being voted for
incubation at Apache and I think it would be a perfect fit for
FtpServer. In that case, the current User interface would be replaced
by the Subject interface:
http://www.jsecurity.org/api/org/jsecurity/subject/Subject.html
What's your thoughts on this?
/niklas
