[Auth]Okay, so how about some code...

[Mason Ham]

Hello one and all:

  It has been a long time since I have posted, and that is mostly cause I have been doing work to make it so that I can make a release to the dotGNU. Basically in a nut shell I have been working on making a dual license for our software. Now before I go further with getting the code under GPL, I am interested in knowing whether or not people on this list are interested the technology I would "donate" to the cause. Basically it is as follows:

 

Good stuff (opinion):

1) It is fully written and works for what it was designed to do. Provide an authentication mechanism that is driven by the needs of the end user, not a service that uses it.

2) It doesn't use ldap or any other directory service. The first module we wrote was for enterprise systems, so it is based on Oracle or SQLServer for the RDBMS.

3) The current code is all java based. Using the java plugging code you can get at it through com though :-)

4) I has the hooks for most of what has been discussed on this list. This included the ability to make a "private" server to respond to requests for authentication.

5) It uses no platform specific code. It runs on Linux, *BSD, Solaris, Win*, AIX, and even J2ME with out any problems.

 

The bad stuff (opinion):

1) The package requires you to install JCE on java based systems. Further you have to install the provider that you want to use. We have tested it with stuff from cryptix and STLabs. We think it will work out of the box with RSA(Anyone got a license from them to use there CryptoJ?) and we think it wont be that bad to use PGP (The new version/company). The MSFT CryptoAPI stuff also works with the alpha-version of that package we have.

2) We haven't made the "personal" implementation yet, but we have proven that you can drive the server off of a simple xml file. We basically need to write the crypto part to make it work, else it is really a two day affair to write the server using the java.net.* classes :-)

3) As far as I can tell from this list, people are pretty tied to ldap, and we never wrote that module yet, although we do have an architecture to make a module that will let the whole system be queried like an ldap directory.

4) We haven't written the full service client side bean yet. So we can't run in all environments out of the box, you have to write code to make it work on none session based systems.

5) It has been developed by the same core five people for more than 5 years .... so basically we didn't "document" everything that we should have, so I think that it is in "schetchy" hand off shape. If you know the in's and out's or Java and SQL no problems if you are a little slack still not problem ... if you are new to Java or SQL .... well....

 

Up for debate as to good or bad (:-?)

1) We haven't written the "DNS" system yet. To be honest, we punted to the end user on this one. Basically we decided that the end user has to provide the name of the server to authenticate with. Yes, we know that that is another step in the process, but we felt that it was a worth while trade off. Think of it as a wizard, and the total cost of SSO so out ways the two step cost of who holds your info. that we just felt it was the write way to go. I mean think about it this way ... Right now I enter my user name and password in three time for three different sites ... that is three screens. Now imagine that you enter your info. server at screen one, then your authentication information once. That is only two screens, so I figure we are ahead one screen and you could make it one simply by having a screen have three fields instead of two :-)

2) We haven't written the system status module yet. This is the system that tells you who, what, when and where your data has been accessed, delivered, queried, denied etc. It is all stored in the db, we simply haven't written the system to get it out yet.

 

Soooo ... on with the code. Here is what you need to write to authenticate a user with our code ... there is nothing on the users side directly, and you only need to have a component (browser or our component) to authenticate. This means that it is useable in app. servers, e-commerce site and even main frames :-)

 

if (!GLMgr.isAuthenticated("acls_object_holder")
 {
  // user not logged in
  // redirect user to GL page
  requestAuthentication(GLMgr.getLoginUri("someServer");
 }

 

The assumption here is that you have place the GLM in your class path. also that you have set up the cryptographic provider correctly (generally that is making a change to the properties file and putting something in the lib\ext directory).

That is it, this will handle checking if there is a currently valid acls object (times, dates, etc are all checked) then using the http protocol will query the server to find out if user is authenticated.

 

So what do I want to know?

One, if we "donate" the code, are people willing to work on it to get it the rest of the way there?

Do people want to write this stuff from scratch? We have been working on the system of the last five years, and so there will be obvious places where the system is build differently than that which is being discussed by the list.

 

So now for my soap box :-) .... I started trying to use LDAP for this project what seems like moons ago ... three years I think ;-) Anyhow, basically when we used our earlier incarnations in "real" code, it became clear that LDAP wasn't up to the "slice and dice" that end users wanted. Also, while the system act's as  proxy for the authentication, it also acts as a proxy for the personalization and the business flow of the information. This is the part where LDAP and it's ilk fall short (IMHO). The system has to provide for things like, LCRS (Least Common Rule Sets). These are simply having the system over ride defaults based on end user desires. A simple example is a web site that says a user name and password is fine for Authentication, but me as a use, I say you need to use a bio-scan device (finger print). IMHO, LDAP doesn't support this as well as a true DB. This leads us to what DB to use. To that extent, we choose implement the system using straight SQL92. No extension or anything. Thus, it is proving to be "easy" to port to other systems (right now I am working on Postgresql). I think MySQL will be painless, although I am concerned with the lack of trans.

All of this being said, I am just wondering if I should bother to put it all into a way that will be useable by the group. Being a true believe in choice, I figure who am I to say that the way that we made is right or even good. I only offer that the way that we went is flexible and holds with the tenants of what dotGNU says, make it for the people by the people. Let's face it, this is really to important to leave to companies ... so .... if people are interested I will finish up with FSF and their legal and get it out. This is going to cost me out of pocket money (which I really don't have :-) so I would like to know where people want to actually go.

Do they want implementation that is ready now today with a bunch of worts, but which I think the group can act as the compound D to cure it ;-) (sorry for the none American TV watching group ... this means it aint right, but he group can fix it :-)

 

Soooo.... let me know what you all want to do.

 

Mason