Posted by Notgiven on 10/06/11 11:39

> LDAP as described here is functioning as a database of valid users
> and passwords, and a method to check access. Alternatives might
> include a MySQL database of users and passwords, a flat file, a
> RADIUS server, or something hardcoded into code.
>
> Issues like whether the passwords are encrypted when stored or
> encrypted when transmitted are implementation details. If you want
> it "secure", you have to describe the threat model. Is the problem
> traffic sniffing? (encrypt passwords when transmitted) Or an
> employee who walks off with a copy of the database (encrypt passwords
> when stored). Sometimes it's not practical to do both.
>
> You also need something that allows or disallows access to particular
> pages. It also has the problem of grouping a set of accesses into
> a "login session" as it is undesirable to make the user enter a
> password on *every* page, and checking on every access can be
> inefficient. PHP code with sessions is one way to do this. Apache
> HTTP authentication is another (although it has disadvantages, like
> not having a "logout" function). You can also use PHP code with
> cookies. Or check IP addresses.

So as I understand it, LDAP is an alternative to userid and passwords in a
database for authenticating.

Regarding sessions, right - I use them in my apps for controlling access to
certain pages.

Not being familiar with LDAP, I thought is was a magic bullet for
authenticating AND intra-application access control. I see not that it is
not. Rather, as I understand it, it is one of several authentication
methods.

Thanks again

[Back to original message]