Page 1 of 1

Authentication libararies

Posted: Thu Apr 27, 2006 9:03 pm
by alex.barylski
Seeing how i'm working on my own right now I figured I'd ask what you all thought made a library like this solid?

When I say solid, I mean, features, capabilities, etc...

For example:
- Data store selection (DB, FLATFILE, XML, etc...)

What existing libraries have you used?

PEAR has a few, but there are others like, phpGACL...

What did you like best about these libraries and what did you not like?

For instance, reading the PEAR AUth docs...I can't say I'm a fan of it's using a callback to display the login form...WTF I say...

Who says I want to store that information in a function? Despite it being possibly optional...I still don't like the idea

Cheers :)

Posted: Thu Apr 27, 2006 9:18 pm
by Benjamin
What in gods name are you building there?

Posted: Thu Apr 27, 2006 9:34 pm
by alex.barylski
agtlewis wrote:What in gods name are you building there?
huh :D

I think it's pretty obvious by the questions I asked, wasn't it? :P

Cheers :)

Posted: Thu Apr 27, 2006 9:36 pm
by Benjamin
I am dense ok. Either your working on a really large project or your working on a bunch of projects. Either that or I am imagining things.

Posted: Thu Apr 27, 2006 10:07 pm
by alex.barylski
agtlewis wrote:I am dense ok. Either your working on a really large project or your working on a bunch of projects. Either that or I am imagining things.
You are correct on every level :)

I am working on a large project...which is composed of many smaller projects...and you are imaging things ;)

Posted: Thu Apr 27, 2006 10:40 pm
by Benjamin
lol

Posted: Fri Apr 28, 2006 1:36 pm
by n00b Saibot
I always toast my own lib 8) Well, I hav my personal lib for everything, and it is constantly improving with time. Trusted and Believable :)

Posted: Fri Apr 28, 2006 2:54 pm
by alex.barylski
n00b Saibot wrote:I always toast my own lib 8) Well, I hav my personal lib for everything, and it is constantly improving with time. Trusted and Believable :)
Thats the problem with PHP...because it doesn't take long to get up to speed in developing software, there are an amazing amount of poorly written classes, libraries, etc...

On the same hand there are fantastic libraries, but there are waaay less of the latter unfortunately...

I would use someone else authentication library, but they are all either incomplete, dependant on one thing or another or lack flexibility...

Like PEAR::Auth...

They use a callback to display the login form...optinally or not I have no idea...when I seen that I started running... :P

I like classes or libraries with plain and simple, well written docs as well...none of which I found thus far justify my time in investment...

So if you've written your own, what were some goals, etc you were striving for?

What kinda of functionality, features and flexibility are built in?

Perhaps we can compare features...or ideas at least anyways?

Cheers :)

Posted: Fri Apr 28, 2006 3:16 pm
by n00b Saibot
Hockey wrote:Thats the problem with PHP...because it doesn't take long to get up to speed in developing software, there are an amazing amount of poorly written classes, libraries, etc...
Scenario may be different with different people... live with knowing guys, get good exposure to finer part of things and improve yourself and the way you code. stay holed up and you lag behind with minimal chances of any kinda improvement.
Hockey wrote:I would use someone else authentication library, but they are all either incomplete, dependant on one thing or another or lack flexibility...
for this I would like to say, when you are looking at others' code, you gotta kee pin mind that 90% of the time, such libraries are implemented as modules which are built around certain core classes of that library. Anywhere I have seen, I see vast no. of modules that are dependant on one or the other. Even PEAR classes are dependant on PEAR base system.

If you were to think my way, my way of true portable code will be a peice of code I can put anywhere and it works without any/little modifications. Vut then, there are some trade-offs and everything can't we the way we want. we can make that upto some degree but if we very carefully take care of that while coding. often while coding libraries we implement certain level of abstraction so that coding becomes modular. But that very thing makes the classes dependant on the abstraction layer. Without SQL_Generator class, I can't use the USER class to do the work for me. I has to have that class. so that's one side of the thing.

the flip side is, if we make it truly portable, one size fits all thing, then all it ultimately becomes is bunch of code which works if you know how. which grows with the features and complexity involved. but which you can put anywhere and it does the work for you. without any glitch, without any unwanted dependencies.

So what says you :)

Posted: Fri Apr 28, 2006 3:38 pm
by alex.barylski
I says...I guess your not interested in sharing ideas of what constitutes a solid, flexible, one size fits all authentication library? :P

Of course, one solution can never fill all holes, but by using abstraction at every corner, we can comes darn close. :)

Cheers :)

Posted: Fri Apr 28, 2006 4:18 pm
by timvw
(imho phpgacl is more about authorization than authentication.. btw, have you checked out pear::liveuser already?)

I suggest something as following as an interface for a portable AuthenticationProvider:

Code: Select all

interface AuthenticationProvider {
 /**
  * Return the result of the authentication attempt
  * @param $credentials the credentials 
  * @return true if authentication was success
  */
 function IsAuthenticated($credentials);
}
Now bring on your implementations ;)

Still haven't found a good/solid/flexible interface for Authorization... How would you define it?

Posted: Fri Apr 28, 2006 5:05 pm
by alex.barylski
(imho phpgacl is more about authorization than authentication.. btw, have you checked out pear::liveuser already?)
I agree...but when I said authentication library I meant everything that encompasses security and access to resources, etc...

...

I just couldn't think of a better name at the time...suggestions? :P

Kerberos would be cool...cuz I've implemented a library which is composed of a triad of sub-components and I believe Cerberos was a three headed guard dog in greek mythology or similar :)

3 headed guard dog...3 components which constitute a whole...I loves little things like when coming up with names :P
Still haven't found a good/solid/flexible interface for Authorization... How would you define it?
I'm working on it... :)

Posted: Fri Apr 28, 2006 8:51 pm
by alex.barylski
Ok, so clearly...I need to rekindle the fire...

Here are some features in which I would personally like to see implemented in a authentication (as in security as a whole - not just authentication) library:

1) Support for any data storage you can imagine (DB, XML, LDAP, FLATFILE, SMTP, etc)
2) A total drop in replacement for existing code...meaning, if you have a database table already setup with 500 users, you shouldn't have to change your schema just to integrate an auth library into it.

This is probably most important from the client programmer perspective as drop-in suggests, you can change one line at a time and update your codebase on a day to day basis. Not change your schema and have downtime for a week or a month because you need to find all occurances of code which need be changed...

Comments, ideas, etc???

Cheers :)

Posted: Mon May 01, 2006 12:14 pm
by silicate
Hey there,
1) Support for any data storage you can imagine (DB, XML, LDAP, FLATFILE, SMTP, etc)
This suggests to me that you intend to have a full ORM/datasource abstraction component dedicated to just the "Auth" package? I definitely don't think that is a practical design requirement. Most people that want a drop in solution don't want to have to configure two different ORM solutions. If you mean that you want them to pass in an existing ORM then you will have to make your Auth package understand how to work with their existing stuff. The last type is just the server page that has your auth package at the start and redirection to a login page if it fails. I say for the time being you don't need to worry about that.
...but when I said authentication library I meant everything that encompasses security and access to resources, etc...
You should work on the two problems seperately.

Authentication (think identification) is determining if the person trying to use the app is who they are saying they are. The typical question being asked is: "Is the password supplied the exact same as the password that the user <mpurdon> has according to our records?"

Authorization is determining if an already Authenticated user has the ability to perform some action. The typical question being asked is "Do the current permissions that the user mpurdon has allow him to <delete the entire hard drive>?"

Authentication is easy. Authorization can be quite complex depending in your granularity. Are you going to have it object based so that you can implement security in terms of CRUD? Or are you going to have it based on generic Operations? Are you going to support Roles? Groups? Hierarchies of each respectively? Will permissions cascade down the hierarchy? If you are going to support any of that, how do you plan to implement it without having the client change their schema?

I think that the reason so many generic auth components "suck" is that it is nearly impossible to implement a generic auth system for anything but the most basic (read Server Pages) applications.

Later,

Matthew Purdon.

Posted: Mon May 01, 2006 9:42 pm
by alex.barylski
This suggests to me that you intend to have a full ORM/datasource abstraction component dedicated to just the "Auth" package? I definitely don't think that is a practical design requirement.
You have the wrong impression then :P
You should work on the two problems seperately.
I am, but they are within the same library of code...
Authentication is easy. Authorization can be quite complex depending in your granularity. Are you going to have it object based so that you can implement security in terms of CRUD? Or are you going to have it based on generic Operations? Are you going to support Roles? Groups? Hierarchies of each respectively? Will permissions cascade down the hierarchy? If you are going to support any of that, how do you plan to implement it without having the client change their schema?
These have all been considered...and honestly I'm not sure I can answer right now...

I have an idea...but nothing concrete enough to publicly announce...

All I can say...is abstraction :P
I think that the reason so many generic auth components "suck" is that it is nearly impossible to implement a generic auth system for anything but the most basic (read Server Pages) applications.
Agreed...I'm working on a drop-in replacement...if I can't make it drop in...then I'll drop it instead... :)

I appreciate your response...and it's genuinity :)

Cheers :)