|
Dass der Einbezug der Benutzer in vielen Fällen nicht nur wünschenswert, sondern zwingend ist, ist eine der Erfahrungen, die man gesammelt hat. Ob es dabei um formal erforderliche Zustimmungen zu AGBs oder um datenschutzrechtliche Aspekte geht - in vielen Fällen muss man eine Interaktion mit dem Kunden durchführen. Dabei kann aber schon die Benutzerschnittstelle zur Herausforderung werden: Bei Microsoft CardSpace wird eine Windows-Schnittstelle angezeigt, bei anderen Ansätzen muss man zunächst eine Authentifizierung beim Identity Provider durchführen, um dann beim Service Provider - auf den ja zunächst zugegriffen wurde - weiter zu arbeiten. Da ein Identity Provider aber oft für viele Service Provider arbeitet, entstehen hier neue Herausforderungen. Dass sich auch Geschäftsprozesse und Geschäftsmodelle verändern, ist aber meist noch eine viel größere Herausforderung für die Unternehmen. So sind beispielsweise die Beziehungen zwischen einem großen Internet Service Provider und den Unternehmen, die Dienstleistungen auf dessen Portal anbieten, sehr klar ersichtlich. Wenn er aber „nur" als Identity Provider agiert, dessen Services anschließend von unterschiedlichsten Service Providern auch außerhalb des Portals genutzt werden, ist es deutlich schwieriger, für alle Beteiligten sinnvolle Geschäftsmodelle zu definieren. Die spannendste Herausforderung ist aber sicherlich die Haftungsfrage. Besonders deutlich wird das, wenn man sich mit dem Modell der Claims beschäftigt, dass Kim Cameron von Microsoft vorgeschlagen hat. Im klassischen Modell der Authentifizierung gibt es eine - in der Praxis zwischen unterschiedlichen Geschäftspartnern auch vertraglich untermauerte - Vertrauensstellung, auf deren Basis sich der Service Provider auf die korrekte Authentifizierung durch den Identity Provider verlassen kann. Im Modell der Claims spielt aber das „Anzweifeln" dieser Claims eine wichtige Rolle. Claims werden präsentiert und vom Service Provider überprüft und anerkannt - oder auch nicht. In der Konsequenz bedeutet dass, dass sich auch die Verantwortung verlagert, hin zum Service Provider. Dass dieser Veränderung ungleich größere Auswirkungen als die technischen Änderungen hat, steht außer Frage. Aber auch sonst gibt es Herausforderungen bei der Haftung. Ein Identity Provider muss ein Geschäftsmodell abwickeln, dass seine Haftungsrisiken abdeckt. Das wird vor allem in Konstellationen von Bedeutung, in denen beispielsweise ein ISP als Identity Provider agiert und darauf Geschäfte unterschiedlichster Tragweite aufbauen. Bei einfacher Interaktion ist das Risiko begrenzt, bei größeren geschäftlichen Transaktionen stellt es sich schon ganz anders dar. Hier müssen auch die Geschäftsmodelle auf den Umgang mit solchen Risiken hin überprüft und gestaltet werden. Federation bleibt also spannend. Und der wichtigste Rat, den man geben kann ist, dass man sich vor allem bei Federation-Projekten mit Ansätzen des user-centric Identity Managements im ersten Schritt auf den Business Case konzentriert und analysiert, ob die Geschäftsprozesse, Geschäftsmodelle und Haftungsfragen funktionieren. Erst dann macht es Sinn, sich mit den wachsenden technischen Gestaltungsmöglichkeiten zu beschäftigen. Auch hier gibt es dann noch manche Herausforderung - wie beispielsweise die der noch fehlenden Roaming-Unterstützung für Information Cards. Deutlich einfacher stellt sich die Situation bei der Nutzung von Federation-Ansätzen innerhalb des Unternehmens oder bei bi-direktionalen B2B-Ansätzen (also die Federation zwischen genau zwei Geschäftspartnern) dar. Hier gibt es mehr Erfahrungswerte. Aber auch hier gilt es zunächst, den Rahmen für die Federation richtig zu definieren, bevor man sich an die Umsetzung macht.
Created: 22.07.08, modified: 01.08.08
|
