Sorry for the somewhat wide distribution, first of all.


I am implementing multiple websites using MySQL as a backend database. So
far, nothing new. However some of these websites will host applications that
are password protected and user-role authorized. Thus it would seem ideal if
we could somehow manage for the website password to be the same as the
database password, so that we can target specific tables / databases for
specific users. One of the databases is to hold financial data, which I
would not want a "role-based" user id (aka "web"/"web") to be able to see.

I *assume* that a possibility like this would greatly benefit several
organizations using MySQL for similar purposes, if these organizations
already have centralized password databases. Nowadays with Microsoft finally
supporting Kerberos by default as the means to store Active Directory
passwords, it would seem to me that a large number of organizations actually
fit that bill.

I would imagine that one of the negative sales aspects of MySQL is and has
been that it supports only a legacy authentication mechanism. Since my
company is a "MySQL Enterprise Ready Partner", I belief this restriction
should be lifted, so that there is yet one more compelling reason for
organization to adopt to MySQL and start saving costs (IT is about getting
more value!!).

Looking at the Work Items at http://forge.mysql.com

So to that affect and after a good long though about integrating LDAP Bind
facilities into MySQL for the purpose of central authentication (at first),
I would like to confirm my thoughts with the "crowd".

Functional Requirements:

FR0001 Utilize centralized passwords so that in a web or
multi-tier environment true SSO can be implemented and user's data
modification can be audited

FR0002 At all times, the standard MySQL password mechanism
as from MySQL 4.1.1 is to preferred and used as default.

Technical Requirements:

TR0001 Implement configuration option in the client
protocol (mysql, libmysqlclient, etc.) to accept an LDAP based password
(e.g. -use-ldap or something similar).
TR0002 If the client opts for -use-ldap, the connection to
the server *must* be SSL enabled, otherwise the connection is refused
without the password being checked (or otherwise made available to the
server). (WL#891, possibly others).
This requirement is already specified in the
GRANT privilege system as described in Section

TR0003 The Client sends the decryptable password over the
wire, prefixed by 'L' rather than '*', so as to indicate to the server that
an LDAP password is used.

TR0004 The normal password check routine is bypassed for
LDAP based passwords, which will be send over the wire in a decryptable

Based on TR0002, the decryptable password cannot be intercepted, as SSL
encrypts the socket layer to prevent interception, so the password is

TR0005 Implement server-side configuration option for
"ldap-server" (in a URI compatible way, i.e. ldaps://ldap.example.com) which
*should* (at the end-user's discretion) use LDAPS rather than LDAP protocol,
again, to keep the password safe.

TR0006 The server checks the password against LDAP, by
decrypting the user.password field (retrieving the user's DN) and binding to
the configured LDAP Server using the DN and the given password.
If this bind succeeds, the password is

TR0007 The MySQL Server *must* only support
LDAP_PROTOCOL_VERSION 3, as this allows for SSF and SASL mechanisms between
itself and the external password database (e.g. Kerberos, RADIUS).

TR0008 Support for OpenLDAP *must* be implemented.
Possibilities to extend this scheme to SunOne, Oracle Identity Server,
Microsoft Active Directory, or Novell Directory *can* be provided.

Required implementation changes:

1) Implement command line option in the client called "-use-ldap" to
indicate that the user wants to use the LDAP based password (for GUI or TTY
based clients).

2) Implement connection option to indicate that the client wants to use
the LDAP based password (for wire-based clients, e.g. PHP).

3) Implement server-side configuration change that allows the end-user
to set the URI of his/her intended LDAP server.

4) make_scrambled_password() must detect the existence of the "{LDAP}"
prefix in the password (PASSWORD() function) and store that password, which
is of '"{LDAP}"<DN>' format, in a decryptable manner in the user.password

5) scramble() understands -use-ldap and uses my_crypt() to create a
decryptable form of the password that is prefixed with 'L' (as opposed to

6) check_scramble() understands that if the first character of message
is 'L', it should verify the password against the configured LDAP Server,
a) decrypting user.password
b) creating a connection to the LDAP server, and setting the connection
c) decrypting the client's password in memory
d) binding to the LDAP using the already established connection
e) destroying the client's password memory region
f) destroying the decrypted user.password memory region
f) verifying the result of the bind from d) above

Would this seem a do-able change? I am trying to adhere at all costs to
FR0002 above, so as not to break existing code / applications.

I would think that the proposed change is also applicable to MySQL Embedded,
if that is configured to check passwords.

Have I missed anything, do you see gaps in the above specification? Please
let me know!!

I will start implementing the above from the 3rd of June onwards, if there
are no comments.

If (enough) comments are of nature that this is not usable/acceptable for
MySQL at any rate, I will keep the change private, and will not disturb you

Otherwise, a discussion about the comments will sure commence, whereupon an
agreement shall be reached, whereupon the implementation shall start.


Guus Leeuw jr.

Search Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcontributions @
postedMay 18, '08 at 10:07a
activeMay 18, '08 at 10:07a

1 user in discussion

Guus Leeuw jr: 1 post



site design / logo © 2021 Grokbase