Das Risiko des Passworts – hinlänglich bekannt, vielfach zitiert. Um das Risiko einigermaßen gering zu halten, begegnet man immer wieder dem Rat, möglichst sichere Passwörter zu verwenden. So sollte es mindestens 8 Zeichen umfassen, einen Mix aus Zahlen und Buchstaben sowie Groß- und Kleinschreibung beinhalten, optimalerweise keine direkten Worte verwenden und Ähnliches.
Viel wichtiger aber noch, nicht an allen Stellen das identische Passwort verwenden! Die Anforderungen sind zwar alle schön und gut, erschweren einem Anwender aber aus Gründen der Usability das Leben in der digitalen Welt ungemein. Denn vermutlich dürfte es den meisten Benutzern schwer fallen sich an 20, 30, 40 oder noch mehr Passwörter der Marke "Ui6eo9Ae" zu erinnern.

Angeregt durch die letzten Artikel fragt sich der eine oder andere was eigentlich doubleSlash mit OpenSource Software (OSS) zu tun hat. Im Folgenden versuche ich mal etwas Licht ins Dunkel zu bringen.

doubleSlash baut seit Anfang an selbst auf OSS. Von Anfang setzt doubleSlash beispielsweise auf eine komplett OSS basierte Infrastruktur. Diese beginnt bei Fileservern mit Samba, geht über Webserver mit Apache und hört bei der Entwicklungsumgebung Eclipse nicht auf. Mittlerweile sind hier und da einige proprietäre Systeme wie z.B. die auf HP OpenMail basierende Groupwarelösung Scalix hinzugekommen. Aber auch diese basieren auf einer freien Linux Distribution. Speziell kommt bei doubleSlash für Serversysteme die Distribution Gentoo zum Einsatz, auf Desktops auch schon mal ein sehr pflegeleichtes Ubuntu.

Microsoft CardSpace wurde bereits in dem früheren Artikel "Zeigt her eure Karten…"  grob eingeführt.
Doch wie läuft eine Authentifizierung mittels CardSpace ab?

Folgende Grafik veranschaulicht die dazu notwendigen Schritte:

Dabei gibt es zwei Möglichkeiten:

1. Szenario mit einer WS-* implementierender Relying Party
2. Szenario mit einer nicht WS-* implementierender Relying Party (normale Webseite),
   Anwendung = Webbrowser)

Szenario mit einer WS-* implementierender Relying Party

1a) Security Token-Anforderung erfragen
1b) Policy beschrieben durch WS-SecurityPolicy wird mittels WS-MetadataExchange zurückgegeben
2) Idenity Card auswählen
2a) CardSpace Identity Selector graut digitale Identitäten aus, die nicht zur Policy passen
2b) der Benutzer kann eine der passenden digitalen Identitäten auswählen
3) Security Token anfragen (WS-Trust)
4) Security Token präsentieren, Übermittlung an Relying Party mittels WS-Security

In USA ist “Bandit” ein häufiger verwendeter Hundename. Seit ca. 2 Jahren ist er auch Namensgeber eines Opensource Projekts für ein Identity Management. Folgerichtig wird ein Hund im Logo verwendet und damit er auch wirklich als Bandit zu erkennen ist, setzte der Initiator dem Hündchen noch eine Maske auf. Gerade so als ob es beim Identity Management darum ginge, möglichst unerkannt zu bleiben.

Doch in Wirklichkeit startete Novell das Projekt, um einen quelloffenen Baukasten mit wesentlichen Funktionen zur Nutzung digitaler Identitäten zu entwickeln. Mit solch einem Framework sollen Softwareentwickler in die Lage versetzt werden, sehr schnell identitätsbasierte Anwendungen entwickeln zu können. Solche Versprechungen wecken grundsätzlich meine Neugier und ich nehme mir Zeit um dieser nachzugehen.

In einem vorhergehenden Blog-Beitrag ist bereits der Ablauf für den Endbenutzer bei einem OpenID-Login kurz angeschnitten worden. Um aber das Konzept hinter OpenID ganzheitlich zu begreifen, ist es wichtig, die einzelnen Schritte technisch nachzuvollziehen. Deshalb möchte ich anhand der nachstehenden Grafik diese detailierter erläutern.

1. Der Benutzer gibt in dem Formular in seinem Webbrowser seine OpenID-Identität ein. Im konkreten Fall verwenden wir wieder http://doubleslash.myopenid.com. Danach schickt er das Formular über den Submit-Button an den Webserver ab.
2. Der Webserver seinerseits verarbeitet den Formularrequest und parst den HTML-Inhalt. Dabei sucht er nach folgendem Tag:

   <link rel="openid.server" href="$OPEN_ID_SERVER">

   An der Stelle ist natürlich anzumerken, dass der Wert für das Attribut “href” die jeweilige URL des OpenID-Servers beinhaltet.

Über SOA, Service Orientierte Architektur, wurde viel geschrieben und noch mehr geredet. Oftmals ist es nur ein neues Etikett für bereits längst bekannte Konzepte. Ganz grob zusammengefasst ist SOA ein Konzept, welches fachliche Funktionalitäten miteinander verknüpft, ohne die Eigenständigkeit der einzelnen Dienste anzutasten oder eine bestimmte Technologie für alle Dienste zu diktieren. Lediglich die Kommunikation zwischen den Diensten muss auf definierte standardisierte Art und Weise erfolgen, dass dieses Konzept funktionieren kann. Beispielsweise über einen Enterprise Service Bus (ESB).

Identity & Access Management befasst sich damit, Identitäten eindeutig zu identifizieren, authentifizieren und mit anderen Daten zu verknüpfen, wobei sich der Begriff Identität nicht auf natürliche Personen beschränken muss. Diese Daten können zum Beispiel Informationen über Berechtigungen, Daten bezüglich der Anwendungspersonalisierung, Personaldaten, Rechnungsinformationen sein. Ein weiteres Beispiel wären Auditinginformationen, die die Aktionen der Benutzer revisionssicher dokumentieren, wie dies in vielen Bereichen aufgrund gesetzlicher Regulierungen von Nöten ist, jedoch auch die Basis für Billing bietet. Man kann behaupten, dass Identity Management überall wichtig ist, wo Informationen jeglicher Art eindeutig zu einer Identität zugeordnet werden muss. Zum Schutz der Privatsphäre muss Identity Management darüberhinaus gewährleisten, dass diese Daten und die Verknüpfungen zwischen diesen Daten nicht von unberechtigten Dritten eingesehen werden können.

In der Musikszene spricht man von Remix, bei Web 2.0 von Mashup. Gemeint ist das neue Zusammenstellen einer Webseite mit Inhalten die eigentlich von einer ganz anderen Seiten stammen. Ein sehr schönes Beispiel hierfür sind die IAM-Wiki-Gadgets zur Suche in der Wissensdatenbank zum Identity & Access Management.
Diese lassen sich über die Javascript-Funktionen ganz einfach auf Ihrer Webseite anzeigen. Einfach das entsprechende Javascript an die Stelle kopieren, wo das Gadget erscheinen soll und fertig.
Einfach mal eine Variante ausprobieren.

In der Vergangenheit haben sich bezüglich sicheren identitätsbasierten Transaktionen im Internet verschiedene Standards entwickelt. Vor allem zwei große Richtungen haben sich dabei herauskristallisiert: Die Protokolle der Liberty Alliance und die WS-*-Protokolle von Microsoft. Bisher sind noch Anpassungsaufwände notwendig, wenn beide Standards miteinander kooperieren sollten, was Investitionen bisher eher zurückhaltend ausfallen ließ.

Der neue Chef der Liberty Alliance, Roger Sullivan, will nun die beiden Lager einander angleichen. Erste Gespräche mit Microsoft verliefen positiv, womit immer wahrscheinlicher wird, dass in den kommenden Jahren die Standards ohne große Anpassungen miteinander arbeiten können werden.

Bislang dürfte wahrscheinlich schon nahezu jeder Internetuser eine Vielzahl an Login-Accounts sein Eigen nennen. Gerade beim Stöbern im Internet ereilt einen sehr schnell die Notwendigkeit einen neuen Account zu registrieren. Sei es auch nur, um mal eben ein erst kürzlich gekauftes Produkt in einem Portal zu bewerten.
Man gibt schnell seine Identitätsdaten an und hinterlässt seine Meinung. Häufig wird der Registrierungsvorgang nur “mit einem Auge” vollzogen, so dass man sich bereits tags darauf kaum mehr an die gemachten Registrierungsangaben erinnern kann.
Demzufolge ist der Benutzer zwar im Besitz von vielen Accounts. Oft kann er sie aber nicht (mehr) nutzen, da er ihre Existenz vergessen hat. Schlicht und ergreifend fehlt einem der Überblick im Accountdschungel. Abhilfe für dieses Problem verspricht der Ansatz von OpenID.