Gerade wenn man als Dienstleister mit vielen Magento-Installationen zu tun hat, stößt man früher oder später auf eine oder mehrere der folgenden Fragen:
Wie war nochmal der Benutzername und das Passwort für genau diesen Shop?
Verwende ich die Zugangsdaten von diesem Shop auch bei einem anderen Shop? Und falls ja, wie stelle ich sicher, dass das niemand ausnutzt?
Habe ich den Login für den Kollegen/Angestellten/Freelancer, der nicht mehr am Projekt arbeitet, auch überall deaktiviert?
Zumindest die beiden ersten Probleme kann man mit der Integration eines zentralisierten Login-Systems wie OpenID in Magento direkt lösen.
OpenID
OpenID ist inzwischen nichts Neues mehr und die meisten haben wahrscheinlich schonmal davon gehört. Version 1.0 der Spezifikation wurde bereits 2005 veröffentlicht. Zwei Jahre später folgte dir Gründung der OpenID Foundation sowie der Verabschiedung von Version 2.0.
Bei OpenID registriert man sich nicht mehr mit Benutzername und Passwort bei jeder Seite (Relying Party) einzeln, sondern identifiziert sich mit seiner OpenID-Kennung (OP Identifier). Die Authentifizierung wird dabei durch den Identitätsanbieter (OpenID Provider) wie zum Beispiel myOpenID oder Google vorgenommen.
Authentifizierung [...] ist der Nachweis (Verifizierung) einer behaupteten Eigenschaft einer Partei, die beispielsweise ein Mensch, ein Gerät, ein Dokument oder eine Information sein kann [...]. – Wikipedia
Daraufhin kann die Seite - abhängig von den jeweiligen Berechtigung - den Zugriff auf bestimmte Inhalte autorisieren oder eben nicht. Der genaue Ablauf ist in der Zend-Framework-Dokumentation recht gut erläutert.
Autorisierung ist im weitesten Sinne eine Zustimmung, spezieller die Einräumung von Rechten gegenüber Anderen, ggf. zur Nutzung gegenüber Dritten. – Wikipedia
Wichtig ist in diesem Zusammenhang die Unterscheidung der beiden ähnlichen Begriffe Authentifizierung (Authentication) und Autorisierung (Authorization), die vor allem im Englischen oftmals auf Auth verkürzt werden und dadurch eine Unterscheidung ohne Kenntnis des Kontextes unmöglich machen. OAuth ist beispielsweise primär für die Autorisierung zuständig, nicht für die Authentifizierung.
Magento-Integration
Obwohl der Standard inzwischen vier Jahre alt ist, habe ich kein ordentliches Magento-Modul gefunden, dass die OpenID-Unterstützung nachrüstet. Lediglich eine Extension bietet den OpenID-Login über einen Drittanbieter an.
Somit ergab sich wieder einmal: selbst entwickeln. Die eigentliche OpenID-Authentifizierung ist in ZendFramework bereits implementiert, muss also "nur" noch in Magento integriert werden. Leider bietet Magento kaum Erweiterungsmöglichkeiten im Admin-Login. Daher muss man entweder den
Adminhtml_IndexController
überschreiben, oder sich in den
core_block_abstract_to_html_after
-Event einklinken, um die Login-Seite zu ändern:
Auf der OpenID-Login-Seite gibt es lediglich ein Eingabefeld für die OP Identifier:
Nach Klick auf "Login" wird man zum OpenID Provider weitergeleitet, um sich dort zu authentifizieren:
Anschließend an die erfolgreiche Authentifizierung beim Provider gleicht das Magento-Modul den OP Identifier mit den Benutzerdaten ab und loggt den Benutzer ein. Dafür wurde ein Feld beim Benutzer eingefügt:
Der Abgleich mit den Benutzerdaten aus Magento erfolgt erst nach der Authentifizierung, da man sonst leicht feststellen könnte, welche OP Identifier überhaupt hinterlegt sind. Das Modul steht auf Github und ist derzeit nur für Magento CE >= 1.6.0.0 getestet. Leider klappt die Authentifizierung über den Google Federated Login noch nicht, myOpenID funktioniert aber. Hat das jemand mit den ZendFramework-Komponenten schonmal realisiert oder muss man für Google eine Speziallösung stricken? Auch sonstige Beiträge/Verbesserungsvorschläge sind natürlich immer gerne gesehen :)
Ausblick
Wie bereits angesprochen werden damit die ersten beiden Fragen gelöst, die dritte Frage lässt sich mit einigen Erweiterungen auch beantworten:
Man identifiziert sich in jedem Shop mit dem gleichen OP Identifier - unabhängig vom tatsächlichen Benutzernamen.
Die tatsächlichen Credentials liegen nicht mehr beim Shop, sondern beim OpenID Provider. Wenn man noch einen Schritt weiter gehen will, kann man selbst einen OpenID Provider aufsetzen (zum Beispiel mit SimpleID). Dann muss man keiner externen Instanz mehr vertrauen und hat alle Authentifizierungsdaten selbst in der Hand.
Mit dem Aufsetzen eines eigenen OpenID Providers kann man auch die dritte Frage lösen. Wird der Account auf dem OpenID Provider deaktviert kann man sich damit auch nicht mehr Shop einloggen. Um auch einen Login mittels Passwort zu verhindern, müsste das Modul noch dahingehend erweitert werden, dass bei vorhandenem OP Identifier kein Passwort-Login mehr möglich ist oder alternativ eine Login-Möglichkeit pro Benutzer oder Rolle vorgeschrieben werden kann. Ideen, Präferenzen, Anmerkungen hierzu bitte in die Kommentare :)
Wie in den Kommentaren zu Jörgs Beitrag bereits angesprochen wollen wir noch einen Schritt weiter gehen und mittelfristig den OpenID Provider an das Microsoft AD anbinden. Damit müsste man Benutzer nicht mehr getrennt im OpenID Provider und AD anlegen. Außerdem könnte man damit ein Throttling der Anfagen an das AD realisieren, um Bruteforce-Attacken auf das AD von außen zu erschweren.
Bisher haben sich mit Karl und Claas zwei weitere Interessierte gefunden, die eine Lösung für alle drei Fragen vorantreiben wollen. Wir werden die Ergebnisse auf Github veröffentlichen und freuen uns natürlich über weitere Unterstützung :)
