From: Guus Leeuw jr Date: May 18 2008 10:06am Subject: sql/password.c List-Archive: http://lists.mysql.com/contributions/7 Message-Id: <001e01c8b8ce$e6f9bf40$b4ed3dc0$@leeuw@itpassion.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C8B8D7.48BE2740" ------=_NextPart_000_001F_01C8B8D7.48BE2740 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello, Sorry for the somewhat wide distribution, first of all. Background: 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 12.5.1.3. 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 fashion. Based on TR0002, the decryptable password cannot be intercepted, as SSL encrypts the socket layer to prevent interception, so the password is safe(Q.E.D.). 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 correct. 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}"' format, in a decryptable manner in the user.password field. 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, by: a) decrypting user.password b) creating a connection to the LDAP server, and setting the connection option for LDAP_PROTOCOL_VERSION to 3 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 further. Otherwise, a discussion about the comments will sure commence, whereupon an agreement shall be reached, whereupon the implementation shall start. Regards, Guus Leeuw jr. ------=_NextPart_000_001F_01C8B8D7.48BE2740--