Page 1 of 2

Best medium for authorization/authentication

Posted: Thu Apr 20, 2006 3:29 pm
by alex.barylski
We've all used MySQL for this in the past, but i'm starting to think LDAP would be a better approach or actually XML...

Flat files are obvious why they are poor choice for anything other than basic AUTH.

But what about LDAP vs DB, etc...

What do you prefer, think is best and why?

Cheers :)

Posted: Thu Apr 20, 2006 3:39 pm
by feyd
I prefer supporting as many different systems as reasonably possible. Although I have yet to work with LDAP in PHP, I have worked a bit with it in other languages. It's okay. I usually set up database first because I always have a database on hand when doing web stuff, overall. Besides, if database authentication is working, so is the database class. :)

Posted: Thu Apr 20, 2006 3:43 pm
by alex.barylski
feyd wrote:I prefer supporting as many different systems as reasonably possible. Although I have yet to work with LDAP in PHP, I have worked a bit with it in other languages. It's okay. I usually set up database first because I always have a database on hand when doing web stuff, overall. Besides, if database authentication is working, so is the database class. :)
I've always used database as well, but it just doesn't seem to fit the bill very well once you get past authentication...

Storing hiearchial(sp) data of any kind in a RDBMS database just feels wrong :)

So I figured I'd look into LDAP or XML and ask here what others thought on the subject...

Not asking for links here peeps...so please NO "Google this" type relpies :P

Thanks Feyd :)

Posted: Thu Apr 20, 2006 4:58 pm
by timvw
If you're going for authentication on unix machines i'd go for a php - pam (pluggable authentication mechanism) which allows you to plugin whatever you want ;) (/etc/passwd, mysql, ldap, you name it :p)

Posted: Thu Apr 20, 2006 11:11 pm
by Christopher
Hockey wrote:Storing hiearchial(sp) data of any kind in a RDBMS database just feels wrong
Why? Any hierarchial system is really a list of nodes with relative or absolute location information about each node.

It is not just the run-time aspect of the choice, it is the ability to build administrative tools to manage the data.

Posted: Fri Apr 21, 2006 9:58 am
by alex.barylski
arborint wrote:
Hockey wrote:Storing hiearchial(sp) data of any kind in a RDBMS database just feels wrong
Why? Any hierarchial system is really a list of nodes with relative or absolute location information about each node.

It is not just the run-time aspect of the choice, it is the ability to build administrative tools to manage the data.
Abstraction dude...I agree at the lowest level, everything in a computer is represented as linear data as ram is nothing more than an array of bytes, but we don't program in assembler anymore do we?

For the same reason that professionals parse using meta-languages like EBNF instead of hand coding a parser. It's a further abstraction from the physical machine and it makes code more organzied and modular and easier to understand in many cases.

RDBMS are not designed to store hierarchial data, although we as developers have found ways of accomplishing this task, tables are linear albeit relational.

Object databases sound like they solve the problem a little better, tackling the problem at the root - but as a previous disscussion went it seemed the community as a whole wasn't interested in switching technologies, so we're stuck with RDBMS for a while yet. :P

I'm not saying it's difficult to associate two linear tables with each other to form a hierarchy, but conceptually I just know the problem can be handled a little better - perhaps taking a hit in performance, but thats a typical side effect of abstraction.

Cheers :)

Posted: Fri Apr 21, 2006 10:48 am
by Oren
Hockey wrote:but we don't program in assembler anymore do we?
I do... At school :P

Posted: Fri Apr 21, 2006 11:39 am
by Christopher
Hockey wrote:Abstraction dude...I agree at the lowest level, everything in a computer is represented as linear data as ram is nothing more than an array of bytes, but we don't program in assembler anymore do we?
Abstraction is done in the interface, not necessarily in the data store. Hierarchical storage systems often have a flat data store, just a DBMSs often do. And Object databases are not necessarily hierarchical, they just store objects in a convenient way.

Posted: Fri Apr 21, 2006 1:40 pm
by alex.barylski
Oren wrote:
Hockey wrote:but we don't program in assembler anymore do we?
I do... At school :P
Well, so do I (although it's been about 2 years) as purely hobby, but I would never develop production/retail code using assembler.

Thats what I meant :P

Posted: Fri Apr 21, 2006 1:42 pm
by alex.barylski
arborint wrote:
Hockey wrote:Abstraction dude...I agree at the lowest level, everything in a computer is represented as linear data as ram is nothing more than an array of bytes, but we don't program in assembler anymore do we?
Abstraction is done in the interface, not necessarily in the data store. Hierarchical storage systems often have a flat data store, just a DBMSs often do. And Object databases are not necessarily hierarchical, they just store objects in a convenient way.
Abstraction can and should be provided at every level...

Posted: Fri Apr 21, 2006 2:49 pm
by Christopher
Hockey wrote:Abstraction can and should be provided at every level...
Fine, but not every level's abstraction is the same. That was my point.

Posted: Mon Apr 24, 2006 9:05 pm
by Roja
Hockey wrote:Storing hiearchial(sp) data of any kind in a RDBMS database just feels wrong :)
I'm curious how you are defining authentication and authorization. More specifically, what do you think the hierarchy is in that data?

Posted: Mon Apr 24, 2006 9:40 pm
by alex.barylski
Roja wrote:
Hockey wrote:Storing hiearchial(sp) data of any kind in a RDBMS database just feels wrong :)
I'm curious how you are defining authentication and authorization. More specifically, what do you think the hierarchy is in that data?
I guess it depends on how you store your users...

1) Users can be linear and have an associated groupid field which indicates which authorization class/group they belong too or you can hardcode permission bits in a single field inside the user data as well.

Code: Select all

user, pass, perms <- [b]perms[/b] could be simple bit settings...
2) Users can contain only that information which is specific to a user (ie: First name, Email, Alias, Password - I usually keep personal details in a DB record so i'm left with only user/pass settings) but therefore must somehow be *grouped* if you wish to provide anything beyond simple authentication.

Using XML would accomplish this task nicely:

Code: Select all

<group name="admin">
  <rights>
    <action1>TRUE</action1>
  </rights>

  <user id="1">
    <user>Joe</user>
    <pass>Schmoe</pass>
  </user>
</group>
Or something to this effect, I haven't put much thought into yet only a few minutes, so easily on structure, etc... ;)

I have used all methods, except the latter, but I am convinced, from my experience it would be ideal and most logical to work with (programatically and manually) never mind conceptually, which is important when writing code...it's also like the media moniker suggests....eXtensible ;)

Opinions, suggestions, etc???

Cheers :)

Posted: Mon Apr 24, 2006 10:18 pm
by Roja
Hockey wrote:
Roja wrote:
Hockey wrote:Storing hiearchial(sp) data of any kind in a RDBMS database just feels wrong :)
I'm curious how you are defining authentication and authorization. More specifically, what do you think the hierarchy is in that data?
I guess it depends on how you store your users...
I would agree. You are choosing to give users attributes that have a hierarchy. You can do so, but you don't have to. (In many cases, it is beneficial not to do so).
Hockey wrote: 1) Users can be linear and have an associated groupid field which indicates which authorization class/group they belong too or you can hardcode permission bits in a single field inside the user data as well.

Code: Select all

user, pass, perms <- [b]perms[/b] could be simple bit settings...
Here, you are giving permissions to a *user*, when in reality, it is more likely that they have *roles*.

Most compliance regulations suggest/encourage/require-by-law that you give groups ("roles") the permissions, and users are made to be "members" of that group.

In that sense, its not hierarchical. A user has a password, and a role. Another user has a password, and a role. Those roles may be related, but they are not (neccesarily) hierarchical.

Windows handles users and roles this way, as does unix, and most other OS's. I've very rarely seen a truly hierarchical user system, which is why your comment confuses me. RDBMS are pretty much ideal for storing user data in every way.

Posted: Tue Apr 25, 2006 11:06 am
by nielsene
And if a given user belongs to multiple groups/roles then the XML implementations start to get complex or ugly, while the database versions don't get to get worse. XML might easier for simple user hierarchies, but I've always been frustrated with them once I pass a certain threshold -- but that might be because I'm much more familiar with DBMS's.