Authentication module

[Immortalin]

Something like devise

[ghost]

Hello,

I'm currently employed at Web Interactive Software Productions WISP Oy here in Finland and our current project is to build a modular web application builder/manager top of caveman framework. Currently we are working on our authentication module. We will definitely take a look at device for ideas.

I will post more info when we have something done and working. The license of the application we are writing will be LAGPL or Lisp GNU Affero General Public License. I will make the repository public when our lawyer gets the license written out.

The difference in LAGPL and AGPL will be the separation of code from data so that it better fits lisp code.

[ghost]

Hi,

Decided to give a little update here as we still have no public repository for it. We have made some of our design choices regarding our authentication and authorization modules and taken influence from the said device and also OWASP. We have decided to have the authentication to be as detached from authorization as possible to allow leeway in using multiple authentication mechanisms or dropping some out.

We are currently relying on postgres to handle the crypting and checking of passwords so the current method of authentication is through plain text POST requests that are passed to the database. This requires that all relevant traffic is https to prevent stealing of passwords. Also the algorithm used by default is bcrypt.

Once authenticated the user is added to the session that is accessed through a cookie, the user may start using they priviledges. The cookie is the standard session cookie set by caveman containing only the session id, all other data including the user assigned to the session is held on server. We will keep working to binding the session to the host with a little more than just the session id that could potentially be forged. Maybe IP binding per session.

On the authorization side, all actions are denied by default if this module is used. This includes even the reading of the application index page. You must then give each request at each route a permission to require for access, one or many. This is to prevent forgetting some routes without being assigned any restrictions even if they need them. This also means that even administrators won't be able to access everything unless you specifically say so. You may use the permission public to make public pages accessible to all.

On the license side, we might not be able to call it LAGPL as there seems to be some restrictions that we might need to add that make it override some of the original GPL. Mainly the changes we are planning include the exclusion of individual constants from being required to be disclosed as they may hold hard-coded passwords and other keys. Also the constants may not hold any functionality or perform actions, so no lambdas in there. this ensures that all code is covered.

Also we are planning to have even code compiled by an application licensed under this license to be subject to the license. This mainly affects dynamically loaded code and some DSLs, but some might see it as intrusive even then. We are planing to use the licensed software to not only make websites but also other software with web interfaces and so they might hold some code that the client may want to hold out of bounds of the license. With this that can only be done by holding the code internally and not showing it to customers. If they do without an NDA, the code is considered published and if it needs to be interpreted by the application, it is subject to this license. They also have to make their customer aware of this.

For these reasons we might call the license WGPL or Wisp General Public License rather than LAGPL. We still intend to keep it compatible so that software licensed under any GPL license is usable under this license.

Hope we can get the repository up soon so others can see what we are making.

[Immortalin]

Why not just with something more business friendly such as the GPL? Being server side software, the AGPL is pretty much unenforceable since none that uses Common Lisp for web development is in any state to pay any significant monetary compensation even if they do get sued. Furthermore, using the affero version is just going to alienate business developers more and Common Lisp is already facing enough competition from the Clojure space. Considering that most of the popular web frameworks today are non-copyleft, putting this under such a restrictive license feels like a step backwards. The GPL's primary objective was and is to ensure the freedom of end users and since in this case the end user is the developer, the copy left clause is nothing but a chain that compromises their freedom and segregates them.

[ghost]

We have considered GPL as an option, but the problem there lies in our ability to enforce anything as all of the software we intend to implement would be web software and as such the corporations using it would have nothing requiring them to distribute the code. It would be the same as to have our software distributed as public domain which we don't want. We have always thought the GPL to be more like "We give you our code and you give us yours." and this is what we are after. It is to us the same idea that Linus seems to be having as he said in BBC interview 2012 '''The fundamental property of the GPLv2 is a very simple "tit-for-tat" model: I'll give you my improvements, if you promise to give your improvements back.''' He has it phrased better though.

We are aware that this form of licensing is very restrictive as it does require even the css-styles of the applications to be subject to this license and we do know that this will be a hurdle. On the other side of things is our reasoning of our business model. The idea is that our clients will be more security aware than those seeking wordpress web stores, and frameworks for their applications and therefore willing to "pay" a little extra for the security focus of the software as we do expect some of them to develop small additions to the software we make for them. This would then apply for everyone else developing these applications even if they would forever be few in numbers. Also as we will be maintaining the software, we would like all of our clients to have at least similar additions to make the maintenance easier, at least for our clients.

This also gives the ultimate end user a way to decide if the service they are seeking is truly safe - which is our main focus - as all code will be available. The focus for security is what this is all about. If our clients are security oriented, they possibly want to show this to their clients and if the end users are security focused, their service provider might want to make this decision.

Other thing we are looking with these license terms is code. Even if it isn't perfect quality, it should be more or less possible to refine this code to become something that can be used by all. If not, at least it showed that this thing needs to be worked on as we keep seeing growing number of poor implementations of a feature.

Furthermore, we won't be selling the services we develop with this software as is, but as parts of a whole cloud enabled system. We are intending to use OpenStack and Docker on a very tiny and security oriented linux. The JVM has some trouble running there, but we have gotten SBCL running nicely even without glibc.

Don't get me wrong, we do know that we are making things differently and taking a huge risk by doing so. We also believe that if successful, it will yield some good profits for not only us but for everyone involved and I'm not talking just about money. The problem lies as you yourself have said in the possible alienation through the fear of the license. We could just be shooting ourselves in the legs by doing this, but we won't know before we try. It is the risk we are taking in hope of the possible profit. As we do hold the copyright, we might make a change to the license later if this doesn't work and no one wants to work with it. Then there would be no or very little other code that would be lost by relicensing as we would probably fall back to vanilla GPL or LLGPL. This remains to be seen.

We do appreciate the concern and would hope to receive more comments and thoughts as we go through this.

Lauri Tšili CBDO Web Interactive Software Productions WISP Oy