Über “Software as Service” wird viel gesprochen man kann auch viel darüber lesen, vernünftige Angebote findet man dagegen selten. Google versucht zwar auf diesem Gebiet mit Beta Versionen zu punkten, das ganze Angebot ist aber eher auf dem Spielniveau und genügt keinesfalls professionellen Ansprüchen. Microsoft versucht nun mit extrem billigen SaS Angeboten für eMail (Exchange), Live Meeting, Sharepoint und Office den Markt zu erobern. Professionelle eMail Services für 15 €/Benutzer im Monat ist mit eigenem oder gehosteten eMail Servern nicht zu unterbieten. Die Deskless Worker Suite mit Sharepoint und Outlook Web Access für 3 $/Benutzer im Monat ist sicher für viele kleine Unternehmen interessant. Das ganze wird gepaart mit einem Vertriebsmodell, das kleinen Firmen beim Verkauf und Betrieb beteiligt. Der Online Service Beta wird aber zur Zeit nur Kunden in USA angeboten. Mit der Initiative von Microsoft kommt nun wahrscheinlich etwas mehr Bewegung in die SaS Landschaft zumindest für Firmenkunden. Völlig offen ist aber, wer den Wettbewerb bei den privaten Benutzern gewinnen wird.  Google versucht zwar in diesen Markt einzusteigen - die Technik und die Zuverlässigkeit des Services sind aber noch äußerst mangelhaft. Bei Google ist aber auch im letzten Jahr keine signifikante Verbesserung sichtbar geworden. Vielleicht klafft da Wollen und Können doch etwas weit auseinander.

Google bietet ja eine Vielzahl von Funktionen im Web an, viele so wie Google Page Creator  (Google Partner Page) ist wohl mehr im Zustand Alpha als Beta! Auf einer Seite (hier das Original), die einen Link für das Gadget Mein Haus enthielt, wies die URL plötzlich auf die Site eines Schweizer Photographen. Nach mehreren Versuchhen wurde dann das Gadget überhaupt nicht mehr angezeigt  - so sieht die Seite http://partnerpage.google.com/microportall.de jetzt aus ohne dass auf der Seite eine Änderung gemacht wurde. Obwohl es heute eine allgemeine Unsitte ist, unreife Software als Kampfmittel im Wettbewerb einzusetzen, sollte man bei einer Firma wie Google wohl doch einen gewissen Mindeststandard an Qualität erwarten können.

Viele Firmen erlauben ihren Mitarbeitern nicht mehr, private eMail mit dem Firmensystem und mit ihrer Firmen eMail Adresse zu verschicken. Damit können sich sowohl der Arbeitgeber als auch der Beschäftigte viel Ärger und Rechtstreitigkeiten ersparen. Allerdings gibt es auch Grauzonen wie z.B. Mitgliedschaft in Berufsverbänden, Teilnahme an Foren oder Blogs im beruflichen Umfeld. Speziell in der IT können viele Professionals zum Vorteil des Arbeitgebers auf den Zugriff zu diesen technischen Informationen auch während der Arbeitszeit nicht verzichten. Allerdings wird es in vielen Foren und Blogs nicht gern gesehen, wenn ”getarnte” Mitarbeiter von Firmen Informationen eventuell sogar von der Konkurrenz (siehe Oracle - SAP) abgreifen.

 Die gängige Lösung für das Dilemma ist ein privater eMail Account, der über den Browser bedient wird, wie z.B. eMail beim Internet Provider Arcor, gmx, 1und1 und Co. oder Google Mail. Dabei werden aber durchaus private Daten wie Linklisten,  oder Cookies für den Zugriff auf dem Firmen PC abgelegt. Interessant ist auch, ob z.B. technische Informationen, die aus Foren als privater Benutzer heruntergeladen wurden, überhaupt im Unternehmen verwendet werden dürfen. In USA läuft zum Thema eMail gerade ein interessanter Rechtstreit, bei dem ein Unternehmen auf die privaten eMail eines ausgeschiedenen Angestellten zugegriffen hat, solange die Zugriffscookies noch auf dem Firmen PC gespeichert waren.  

Eine mögliche saubere Lösung ist z.B. für private Zugriffe, einen anderen Browser z.B. Internet Explorer anstatt Firefox zu verwenden und die Optionen so zu wählen, dass keine permanenten Daten gespeichert werden. Viele Benutzer haben sich aber bereits angewöhnt, Recherchen auch im beruflichen Umfeld vom privaten PC aus zu machen. Bei diesem Blog werden z.B. über 30% der Zugriffe nach 21 Uhr gemacht - wahrscheinlich wenn die Kinder im Bett sind.      

Viele Benutzer aber auch viel Produktmanager meinen, dass man ein gutes Produkt einfach in einer “offenen” Umgebung erhält. Man schafft eine “Plattform” und läßt dann freiwillige in aller Welt dann neue Funktionen basteln. LINUX wird hier immer als Beispiel angeführt. Dabei vergisst man, dass LINUX einfach die xte Version des uralt LINUX Systems ist und Linus Thorwald autoritär und wie ein Zerberus über die Systemarchitektur wacht. Er spielt also die Rolle eine typischen Produktmanagers.

Mit der Plug-Ineritis bei fast allen Systemen (Internet, Explorer, Windows Desktop, Firefox, Google, … ) bekommt man zwar schnell viele Mini-Funktionen, die aber früher oder später nicht mehr funktionieren, weil die Hersteller die Lust verloren haben oder bei Änderungen der Plattform nicht nachgezogen wird. Ähnlich ist es mit Services im Internet, Widgets, Gadgets und Co. Ganz wenige dieser Services im Web funktionieren länger als ein Jahr! Ganz besonders schlimm ist es zur Zeit bei Google, wo sich viele “kreative” ITler ansiedeln aber niemand den unangenehmen Job eines Produktmanagers macht. Im Rennen um immer neue Features wenden sich auch konventionelle IT Firmen wie IBM, Microsoft aber auch SAP dem Chaos Modell zu, dessen zentrales Qualitätsprinzip das Austesten von unfertiger Software durch die Kunden ist.  Ausser ein paar “Freaks” ist dabei aber niemendem gedient. Wirklich gute Systeme, deren Funktionen sinnvoll gestaffelt sind und deren Architektur der Benutzer unbewusst verstehen und über Jahre nutzen kann, entstehen mit diesen Methoden nicht.

Normale Benutzer sollten nur die Basisfunktionen eines Systems verwenden (zum Glück sind sie häufig schon damit überfordert) und zusätzliche Features und Gadgets nur dann nutzen, wenn sich der Aufwand für die Pflege lohnt. Man muss aber jederzeit damit rechnen, dass der Serice kurzfristig eingestellt wird - genau wie im richtigen Leben!         

Der Zugriff zu Google Anwendungen wird mit Cookies so gestaltet, dass der Benutzer nicht immer wieder Name und Passwort eingeben muss. Das ist besonders für Laien sehr angenehm. Etwas überrascht ist man dann allerdings wenn plötzlich folgende Meldung von Google auf dem Bildschirm erscheint:

 ——————————————————————————-

Es tut uns leid, aber …

… Ihre Anfrage ähnelt automatisierten Anforderungen, wie sie von Computerviren oder Spyware-Anwendungen verwendet werden. Zum Schutz unserer Nutzer können wir Ihre Anfrage zum jetzigen Zeitpunkt nicht verarbeiten.

Wir werden Ihren Zugriff schnellstmöglich wiederherstellen. Versuchen Sie es in Kürze wieder. Falls Sie den Verdacht haben, dass Ihr Computer oder Netzwerk infiziert sein könnte, sollten Sie ein Virenprüfprogramm oder einen Spyware-Entferner ausführen. So können Sie sicherstellen, dass Ihre System frei von Viren und sonstiger missbräuchlicher Software ist.

Falls dieser Fehler ständig angezeigt wird, können Sie das Problem eventuell lösen, indem Sie das Google-Cookie löschen und danach Google erneut besuchen. Spezifische Anleitungen für Ihren Browser erhalten Sie in der Online-Hilfe des Browsers.

Sollte Ihr gesamtes Netzwerk betroffen sein, lesen Sie die weiteren Informationen in der Google Websuche-Hilfe.

Wir entschuldigen uns für eventuell entstandene Unannehmlichkeiten und hoffen, Sie bald wieder bei Google begrüßen zu dürfen.

—————————————————————————

Was ist passiert? Beim Testen von Browsern waren zufällig der Opera Browser und der Internet Explorer gleichzeitig aktiv und damit wurden zwei verschiedene Google Cookies für den Zugriff benutzt. Das sollte eigentlich kein technisches Problem sein. Jedoch hat die Google Security Truppe da wohl eine Überreaktion eingebaut. Na ja, da gibt es wohl sicher noch viel zu tun bis der Zuatz BETA bei Google Apps gestrichen werden kann.  

Besonders unangenehm ist, dass der Internet Exporer keine Möglichkeit hat, Cookies per Anwendung zu löschen (der Opera kann das!). Sollte man bei Tausenden von Benutzern zur Problemlösung alle Cookies löschen müssen, sollte sich der Administrator wohl besser gleich nach einem neuen Job umsehen.       

OpenID ist ein einfaches Verfahren mit dem Benutzer mit einem Benutzernamen und einem Passwort auf viele Websites zugreifen können. Der Benutzer meldet sich zuerst bei einem beliebigen OpenID Anbieter mit benutzername und Passwort an.  Er erhält dann eine OpenID in URL Form wie zum Beispiel:  http://benutzername.meinopenid.com .

Meldet man sich nun bei einer Site an, die OpenID unterstützt, wird ein Login Formular ähnlich  http://spielerkabine.net/login angezeigt.

Dort gibt man nun seine persönliche OpenID anstatt wie üblich Benutzername und Passwort an. Danach wird man auf die Login Seite des gewählten OpenID Providers (hier im Beispiel Verisign) umgeleitet. 

Das sieht zunächst nicht nach einer großen Erleichterung aus, da man anstatt wie üblich Benutzername und Passwort auch noch den OpenID eingeben muss. Ist man jedoch bei seinem OpenID Provider bereits eingeloggt, tauschen das Zielsystem und das OpenID System die Login Anfrage/Bestätigung automatisch aus. Der Benutzer muss damit nur noch seine OpenID angeben, die man sich natürlich leicht merken kann und die man ähnlich wie die eMail Adresse auch nicht geheimhalten muss. Der OpenID ist dann nur noch durch das Passwort gesichert, was bei vielen Sicherheitsfans starke Bedenken auslöst. Manche OpenID Provider bieten deshalb eine zusätzliche Sicherheitsstufe an, bei der ein Zertifikat anstatt einem Passwort verwendet wird. Dieses Zertifikat kann auch ein sicheres Zertifikat auf einer Smartcard sein. Damit kommt man mit OpenID schon ziemlich meinem 2003 beschriebenen Wunschverfahren zur persönlichen Identifikation nahe.  

Natürlich muss man sich auch bei Verwendung des OpenIDs registrieren, wenn man zum ersten Mal auf eine personalisierte, geschützte Site zugreift. Die Registrierung wird aber dadurch erleichtert, dass die im OpenID gespeicherten Profildaten mit einem Klick in die neue Site übernommen werden können.   

Für Service Anbieter ist es äusserst interessant die OpenID Funktionalität anzubieten, da ja die Benutzer sich zunächst immer auf ihrer OpenID Site einloggen müssen. Deshalb bieten Firmen wie Google, IBM, Microsoft, Yahoo, Technorati oder auch WordPress OpenIDs an. Man kann zum Beispiel  den Benutzernamen und das Passwort von WordPress (das man z.B. für seinen Blog verwendet) auch als OpenID z.B. ähnlich http://myname.wordpress.com  verwenden. Der Teufel steckt aber wie immer im Detail. OpenID ist zwar “standardardisiert” aber trotzdem können die Implementierungen von Zielsite und OpenID Site inkompatibel sein. Nach meiner Erfahrung funktionieren Verisign OpenIds im Format http://myname.pip.verisignlabs.com recht gut, da die meisten Programmierer auch mit diesen OpenIDs testen.

Eine wesentliche Erleichterung verspricht OpenID bei mobilen Anwendungen. Man muss dann am Handy nur einmal Benutzername und Passwort eingeben!

Hat man nun einen OpenID so ist es nicht ganz einfach, Sites zu finden, die OpenID auch unterstützen. Alle möchten halt OpenID Chef und nicht OpenID Diener sein. Die Basissicherheit bei OpenIDs beruht bei den üblichen Registrierungsmethoden auf der eMail Adresse und sind damit nicht sicherer als bei üblichen Verfahren mit Benutzername und Passwort. Insgesamt ist die Frage Sicherheit komplexer, da man eine mehrgliedrige Sicherheitskette benutzt, die ja immer so stark wie das schwächste Glied ist. Deshalb sollte man zur Zeit OpenID bei Sites, wo es um Geld oder  Bestellungen geht, nicht verwenden. Bei den vielen “social” Diensten kann OpenID das Leben im Web aber wesentlich erleichtern.   

Im Web findet man eine Vielzahl von Verfahren, um den Zugriff auf persönliche Daten in Portalen und speziell im Web 2.0 Umfeld zu sichern. Je mehr Sites Benutzername und Passwort verwenden, desto größer wird die Wahrscheinlichkeit, dass die Benutzer Name und Passwort vergessen. Deshalb ist es gängige Praxis, neue Passwörter an die vom Benutzer angemeldete eMail Adresse zu schicken. Die eMail Adresse ist damit die Verbindung zur Identität des Benutzers. Wer auf die persönliche eMail zugreifen kann, kann auch Passwörter neu beantragen oder ändern.  

Für die eMail Adressen- und Berechtigungsverwaltung gibt es zwei wesentlich unterschiedliche Verfahren

1. Man melder sich bei einem eMail Provider wie z.B. Telekom, Arcor, GMX, Google usw an. Dabei schließt man einen Vertrag zu den jeweilgen Geschäftsbedingungen des Anbieters ab. Bei Google beinhaltet das z.B. dass in der eMail Anwendung des Benutzers Werbung angezeigt wird. 
2. Man besorgt sich eine eigene Domain von einem Anbieter, die auch eMail Service beinhaltet. Das hat den Vorteil, dass man eigene eMail Adressen z.B. in der Firma oder im Verein vergeben kann, ohne dass jeder einzelne Benutzer einen Vertrag mit dem Anbieter abschließen muss. Allerdings ist der Domain Owner für die vergebenen eMail Adressen verantwortlich und kann diese auch ändern. In der eigenen Domain kann man auch sinnvolle Benutzernamen wählen ( z.B. meinname@mydomain.com) und auch mehrere Identitäten/eMail Adressen mit Weiterleitung an die Hauptadresse einrichten. Der eMail Administrator kann eMail umleiten, eine Kopie der eMail automatisch an andere Benutzer schicken oder die eMail Adresse löschen.  

Die Sicherheit im Web wird also im wesentlichen dadurch bestimmt, wie eMail gehandhabt wird. Ich bevorzuge für mich die 2. Methode und empfehle diese auch für Portale und soziale Netzwerke. 

Bei offenen, privaten Portalen haben die Benutzer in der Regel selbstgewählte eMail Adressen und sind nicht gewillt, andere eMail Adressen zu verwenden, während in geschlossenen Firmennetzen die eMail Adressen zentral vergeben werden. Offene Systeme müssen also in der Lage sein, mit beliebig gewählten eMail Adressen zu arbeiten. 

In Sharepoint kann man inder Regel (nicht bei allen Hosting Anbietern!) die beliebige eMail Adresse des Benutzers als Benutzername verwenden und Benachrichtigungen über Änderungen oder Aufgaben im Workflow an beliebige eMail Adressen automatisch versenden. Allerdings gibt es keine Möglichkeit eMail Adresslisten zentral einzurichten oder zu verwalten. Hierfür sollte man nach Meinung von Microsoft die Microsoft Kommunikationssoftware verwenden. Das ist aber bei offenen Systemen nicht realisierbar.

Bei Google Diensten ist es zum Teil zwingend vorgeschrieben, dass die Benutzer eine Google eMail Adresse haben (und damit auch einen Vertrag mit Google eingehen!). Das ist für öffentliche Portale mehr als hinderlich.  

Eine recht interessante Methode ist es, Mailing Verteiler Listen für Gruppen bis zu 100 Teilnehmern zentral in Google Mail zu verwalten und diese den Sharepoint Nutzern und den Sharepoint Funktionen zur Verfügung zu stellen.  In den Google Mail Verteiler Listen kann man beliebige Adressen (nicht nur Google Adressen) angeben. Damit kann man eine zuverlässige, flexible, kostenfreie Kommunikationsinfrastruktur für kleinere Gruppen aufbauen.

Schöner wäre es natürlich, wenn die eMail (und Messaging) Funktionen z.B. in  Sharepoint wirklich integriert wären. Da steht sich aber Microsoft wohl selbst mit seinen unterschiedlichen Firmenphilosophien im Weg.

Sharepoint liefert für kleinere Projekte eine durchaus brauchbare Infrastruktur. Problematisch kann es aber werden, wenn mehrere Sharepoint Projekte und J2EE Lösungen integriert werden sollen. Viele Firmen haben hunderte von Sharepoint Subsites generiert, die man nachträglich nur schwer wieder integrieren kann. Andererseits sind J2EE Portale wie z.B. der IBM WebSphere Portal Server für kleinere Projekte kaum wirtschaftlich einzusetzen.  Auch große Firmen haben Probleme, die Infrastruktur ohne sofort nutzbare Anwendungen und aufwändige Schulung der Mitarbeiter einzusetzen. Es kann durchaus Sinn machen, die Portaltechnologie z.B. mit Sharepoint einzuführen und später auf ein integrierendes J2EE Portal umzusteigen. Mit .Net Extensions für das IBM WebSphere Portal  wird ein interessanter Integrationspfad angeboten.  .Net Programmierer können J2EE Portlets in ihrer gewohnten Entwicklungsumgebung erstellen und damit die Integration erleichtern.  Kombiniert man dies mit der Mainsoft Integrations Software, kann man Sharepoint Sites in WebSphere Portal integrieren. Dies ist durchaus eine interessante Möglichkeit die proprietäre Microsoft Welt zu öffnen. 

Offensichtlich wollen viele Benutzer sich nicht auf eine proprietäre Plattform zwingen lassen, obwohl alle Hersteller dies immer wieder versuchen.

Vodafone bietet für 9.95 € mit Vodafone Live eine Flat Rate für den Handy Zugang zum Internet an. Allerdings muss man dabei den Zugangspunkt Vodafone Live benutzen. Damit funktionieren aber nur spezielle Zugriffe zu http://vodafone.live.com . Wirkliche Zugriffe zum Internet z.B. über Opera Mini funktionieren damit nicht - man kann nur das Unterhaltungsangebot von Vodafone Live nutzen. Die Services von Google Mobile, Sharepoint u.a. kann man damit nicht nutzen.  

Mit dem Tarif Volume PDA von Vodafone bekommt man z.B. für 9.95 € im Monat (30 Mbyte) bei Benutzung des Opera Mini Browsers dagegen einen vollen Zugriff (Zugriffspunkt WPRS-GPRS) zum Internet. Die Grenze von 30 Mbyte im Monat erreiche ich parktisch nie, da der Opera Mini Webseiten stark komprimiert und nur wirklich benötigte Teile der Webseiten überträgt. 

Das RSS Scroller Widget zeigt RSS Einträge im Durchlauf an (Beispiel).  Dabei kann man die Durchlaufgeschwindigkeit variieren. Das Widget kann man in eine eigene Webseite, ein Sharepoint Webpart (Text Editor Webpart), iGoogle, Facebook usw einbetten. Damit kann man wichtige Nachrichten gezielt und effizient an die Benutzer weitergeben.