Die letzte grosse Herausforderung im Internet ist die Information von Passwoertern und Accounts bei verschiedenen Webservices und Anbietern. Egal ob beruflich oder privat: Die Liste der zu verwaltenden Accounts, die einem bei dem einen oder anderen Anbieter zugeteilt wird und deren Information man sich am liebsten merken sollte, wird immer laenger. Neulich erzaehlte mir ein Kollege, dass er sich jeden Monat 256 Passwoerter von verschiedenen webgestuetzen Tools oder Webseiten merken muss. Und am liebsten die Passwoerter auch einmal im Monat aendern soll. Gott bewahre!
Der Trend geht dann eindeutig dazu, dass man ueberall dasselbe Passwort verwendet (sofern man einen laesst) oder nur noch einfach zu merkende Passwoerter verwendet. Dadurch wird natuerlich das blanke Gegenteil erreicht. Man wollte doch eigentlich Sicherheit verbreiten und scheitert weniger an der Bequemlichkeit der Benutzer als vielmehr deren Unvermoegen und Unverstaendnis.
Deswegen sehe ich es als letzte grosse Herausforderung an, sich einmal ins "Internet" einzuloggen und dann auch Zugriff auf seine Informationen zu haben. Ein paar Ansaetze gibts schon in der Vergangenheit:
Das Konzept heisst also Single Sign On - ein Account fuer alles. Dazu brauche ich erstmal eine beliebig grosse Anzahl von passwortgestuetzen Webseiten, die ich alle in meiner Hoheit habe und den Wunsch, das alles zu zentralisieren und die SIcherheit zu erhoehen.
OpenSSO ist, oder vielmehr war eine Enterprise-Loesung zum Identitymanagement von Oracle/SUN. Zugrunde liegt eine Java-Applikation mit SUN-Directory-Server als Config-Store und Auth-Store. Der Dienst ist ueber eine zentrale Internetadresse erreichbar. Die zu sicherenden Webservices bekommen einen Agent verpasst. Zwischen Agents und OpenSSO-Server werden Agreements ausgehandelt in Form von Namen und Passwoertern, mit denen den Agents erlaubt werden, mit dem OpenSSO-Server zusammenzuarbeiten.Das Prinzip ist dann recht einfach: Ich moechte Service A benutzen, dieser kennt mich nicht, schickt meine Anfrage zum OpenSSO-Service, der fordert mich auf einzuloggen und schickt dann bei Erfolg meine Credentials in Form eines Session-Cookies zum Service A zurueck. Unter der Hand haben die zwei dann ausgehandelt, dass das mit dem Session-Cookie ich bin. Das Logout funktioniert dann aehnlich. OpenSSO wird heute von http://forgerock.com als OpenAM weiterentwickelt.
Josso ist eine aehnliche Loesung wie OpenSSO - nur etwas leichtgewichtiger. Das tut dem Funktionsumfang aber keinen Abbruch. Josso gibt es als Webapp im Webcontainer von http://www.josso.org. Auf http://sourceforge.net/projects/josso/ gibt es aber auch fertig konfigurierte Tomcats mit der Josso-Webapp. Einfach die neuste Version runterladen, und auspacken, java-runtime jre auf dem Linux-System seiner Wahl installieren und dann gehts fast los.In /usr/local/apache-tomcat-6.0.29_josso-1.8.3/lib sind noch ein paar Anpassungen notwendig:
josso-gateway-config.xml: Hier sind weitere Config-Dateien fuer Identity-Stores zu definieren. Wahlweise brauchen wir den josso-gateway-ldap-stores.xml oder josso-gateway-db-stores.xml, den wir in die Datei einbinden muessen. LDAP oder ActiveDirectory waer zwar schick, aber ich beschreibe das Vorgehen mal an einer relationalen Datenbank. Altbacken habe ich mich fuer MySQL entschieden und habe in josso-gateway-db-stores.xml die Connect-Parameter zu konfigurieren:
<db-istore:jdbc-store
id="josso-identity-store"
driverName="com.mysql.jdbc.Driver"
connectionURL="jdbc:mysql://192.168.0.10:3306/ben"
connectionName="josso"
connectionPassword="josso"
[...]
Damit die Verbindung klappt. muss ich noch den konfigurierten MySQL-JDBC-Treiber von mysql.com herunterladen und ins selbe Verzeichnis kopieren: mysql-connector-java-5.1.15-bin. Ausserdem brauche ich noch eine MySQL-Datenbank. Das Beispielschema ist fuer Oracle und muss etwas angepasst werden (varchar statt varchar2). Ausserdem sind die Felder fuer Login etwas zu klein. Hier ist ein Beispiel fuer MySQL:
DROP TABLE IF EXISTS `JOSSO_ROLE`;
CREATE TABLE `JOSSO_ROLE` (
`NAME` varchar(16) NOT NULL,
`DESCRIPTION` varchar(64) default NULL,
PRIMARY KEY (`NAME`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
--
-- Table structure for table `JOSSO_USER`
--
DROP TABLE IF EXISTS `JOSSO_USER`;
CREATE TABLE `JOSSO_USER` (
`LOGIN` varchar(16) NOT NULL,
`PASSWORD` varchar(64) default NULL,
`NAME` varchar(64) default NULL,
`DESCRIPTION` varchar(64) default NULL,
`EMAIL` varchar(64) NOT NULL,
PRIMARY KEY (`LOGIN`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
--
-- Table structure for table `JOSSO_USER_PROPERTY`
--
DROP TABLE IF EXISTS `JOSSO_USER_PROPERTY`;
CREATE TABLE `JOSSO_USER_PROPERTY` (
`LOGIN` varchar(16) NOT NULL,
`NAME` varchar(255) NOT NULL,
`VALUE` varchar(255) NOT NULL,
PRIMARY KEY (`LOGIN`,`NAME`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
--
-- Table structure for table `JOSSO_USER_ROLE`
--
DROP TABLE IF EXISTS `JOSSO_USER_ROLE`;
CREATE TABLE `JOSSO_USER_ROLE` (
`LOGIN` varchar(16) NOT NULL,
`NAME` varchar(255) NOT NULL,
PRIMARY KEY (`LOGIN`,`NAME`),
KEY `NAME` (`NAME`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Es werden also nicht nur Username und Passwort sondern auch verschiedene Rollen in der Datenbank vorgehalten, in die ich User einweisen kann (role1, role2 gibts schon als Beispiel in der Originaltabelle von http://www.josso.org/confluence/display/JOSSO1/Database+Setup
In der josso-gateway-selfservices.xml konfigurieren wir noch das Versenden von Freischaltmails bei vergessenem Passwort. Das wird spaeter die Kernfunktionalitaet unseres Dienstes. In die Datei gehoert ein Mailtemplate (Beispieldatei passwordVerificationEmail.vm) und Angaben zum versendenden Mailserver und Mailabsendeinformationen.
Unser Webservice soll unter SSL erreichbar sein. In Tomcat gibts da 2 Moeglichkeiten. Die erste ist die Verwendung von keytool aus dem jdk-Packet. Damit wird ein Tomcat-eigenes Zertifikatformat erstellt, die zum Beispiel mit OpenSSL nicht identisch ist. Der Umwandlung der Zertifikate ist ... aeh, abenteuerlich. Um OpenSSL im Tomcat verwendenzu koennen, muss das Tomcat Native Paket installiert werden. Unter Opensuse 11 findet man es als libtcnative-1-0, in OpenSuse 10 hilft nur selber bauen und installieren des tomcat-native-1.1.20-src.tar.gz. Wenn die Libs in das Java, welches im Tomcat Verwendung findet, eingebunden sind, kann ich in
/usr/local/src/apache-tomcat-6.0.29_josso-1.8.3/conf/server.xml einen SSL-Connector via APR AJP mit OpenSSL-Zertifikaten konfigurieren:
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
SSLEnabled="true"
SSLCertificateFile="/etc/apache2/server.crt"
SSLCertificateKeyFile="/etc/apache2/server.key" />
/usr/local/apache-tomcat-6.0.29_josso-1.8.3/bin/startup.sh
Unser Tomcat wird gestartet. http://192.168.0.41:8080/josso/signon/login.do
Josso-Agents laufen auf den zu schuetzenden Applikationen, die zur Authentifierung den SSO-Server nutzen sollen. Wir benoetigen josso-apache22-agent-1.8.3-.tar.gz. Dort gibt es eine Fuelle fuer Agents in verschiedenen Applikationen. Fuer Apache 2.2 muessen wir den Agent mit Angabe des Apache APR und Verwendung der OpenSSL-Libs kompilieren. Man brauch also apache2-devel und openssl-devel-Pakete. Die kompilierte Lib kann ich /etc/apache2/conf.d/josso.conf einbinden:
LoadModule auth_josso_module /usr/lib/apache2/libmod_auth_josso.so
Ein "make install" wird zwar in /etc/sysconfig/apache2 das Modul automatisch versuchen einzubinden, aber irgendwie funktioniert das unter Suse nicht so richtig. Das zu schuetzende Verzeichnis wird dann in der httpd.conf bepuschelt:
<Directory "/http/virtual/www.eumel.net/geheim">
AuthType JOSSO
AuthName "MyApacheWeb"
Require role "role2"
GatewayLoginUrl "https://192.168.0.41/josso/signon/login.do"
GatewayLogoutUrl "https://192.168.0.41/josso/signon/logout.do"
GatewayEndpoint "192.168.0.41" 443
GatewayEndpointSSLEnable On
SessionAccessMinInterval 60000
</Directory>
Nach Apache-Restart sollten wir nach Aufruf unserer Geheim-URL zum SSO-Service weitergeleitet werden, dort unsere Credentials eingeben und per Redirect dann in unserem loginpflichtigen Bereich landen. Der Clou: Mit dem gespeicherten Session-Cooki und der Funktion "angemeldet bleiben" kann ich diesen Bereich ohne Eingabe des Passworts am SSO-Server immer und immer wieder aufrufen. Mein Apache-Webserver wird bei jedem Aufruf die Credentials aka Cookies am SSO-Sevrer auf Gueltigkeit ueberpruefen. Und wenn ich das Cookie verlorenhabe, kann ich ueber die Funktion "Passwort vergessen" mir vom SSO-Server ein neues per Mail zuschicken lassen und per Freischaltlink freischalten.