First off: the forum is the best place to write technical questions of this sort, so that the whole team can respond to issues as appropriate :-)
We want to let site developers create the best user experience possible on their site. I don't think that a link off to a separate form provides this. For sites that support OpenID, it should be included in the default log-in form - perhaps with a radio button that switches between email/password and openid authentication. Of course, for sites that don't support openid, the login form should be left as-is.
Log would look roughly as follows:
(o) Regular login
Email: [_________]
Password: [_________]
( ) OpenID
And would change to this when you click the radio button. The SelectionGroup field type can help create this kind of UI.
( ) Regular login
(o) OpenID
OpenID URL: [___________]
I would recommend setting up a configuration method such as LoginForm::allow_openid() that triggered the changing of the behaviour. Alternatively, you could use the authenticator classess mentioned below to go Security::allow_auth('OpenIDAuthenticator').
Another other thing that you're going to have to mess with is the authentication mechanism. Currently LoginForm::performLogin() calls Security::authenticate() to check a username/password in the database.
Perhaps you should have a number of authenticator classes, and the log-in form specifies which of these authenticators is being used.
abstract class Authenticator
* abstract function authenticate();
* abstract function getLoginFields();
* abstract function getMethodTitle();
class MemberAuthenticator extends Authenticator
* implement authenticate as currently defined in Security::authenticate()
* have getLoginFields() return username and password
* have getMethodTitle() return "Reular Login";
class OpenIDAuthenticator extends Authenticator
* Put your authentication code here. There will probably be some redirection to the OpenID provider, and redirection back; you may need to make class OpenIDAuthenticator_Controller extends Controller to handle the responses (this will be accessible as http://www.yoursite.com/OpenIDAuthenticator_Controller)
* use getLoginFields() and getLoginTitle() to provide the changes to the log-in form
class LDAPAuthenticator extends Authenticator
* This would be another good one to implement
For this to work most appropriately, I would suggest creating a new method on Security that was an array of form data instead of the username and password variables. To preserve backward compatability you'll want to keep Security::authenticate() working.
I would suggest that you create a "stub" Member object for anyone who logs in via OpenID. Perhaps you need to add a Username or OpenIDURL field to the Member object. Username would probably be more widely usable - we don't want to add lots of fields to the core database that are only used in the minority of cases.
You'll also note that I've suggested that you re-structure the log-in form to make use of a getLoginFields() method on each active authenticator. This would be a bit more work, but will make it easy to add new authentication mechanisms to the system. This will be particularly useful for people wanting to do this like integrate in, say, a phpBB forum by using phpBB's login scheme.