CIAM – also Customer- (Consumer-) IAM ist in vielen Unternehmen eine Herausforderung. Oft wird es einfach als Teil von IAM gesehen – gleiche Technologie aber andere Zielgruppen. Das ist zwar technisch gar nicht so falsch, aber in der Praxis wird damit CIAM völlig unterschätzt – und das hat kurzfristig interne und mittelfristig externe Auswirkungen.
Wie sieht das CIAM von der konkret, praktischen Seiten aus? Was ist dabei zu berücksichtigen und vor welche Herausforderungen steht man dabei? Wir beleuchten das Thema basierend auf konkreten Erfahrungen.
Herausforderung 1: Die Rolle der IT-Infrastruktur mit Komponenten und Standards
Ein wesentlicher Faktor ist jener der IT-Infrastruktur. Diese verantwortet das Identity- und Access Management (IAM) und muss die Unterschiede zwischen B2E-IAM und CIAM kennen oder kennenlernen. Protokolle wie SAML und OAuth 2.0 sind die Hauptkomponenten der Identity-Provider (IDP), unterstützt diese und ermöglichen so schnell die Anbindung von Anwendungen an das Access Management. Die Authentifizierung findet gegenüber dem IDP statt. Dabei erhält die Anwendung einen Token, der die Identität des Anwenders nachweist und der Anwender hat die (positive) Erfahrung des Single-Sign-On – einmal anmelden und fertig.
In der üblichen Windows-Infrastruktur eines Unternehmens gibt es eine initiale Authentifizierung am Active Directory. Auch hier gibt es SSO-Mechanismen, z.B. die Integrierte Windows Authentifizierung (IWA, basierend auf Kerberos). Beim IDP sprechen wir allerdings über den Identitäts-Provider, der neben den Identitäten (die oft im AD liegen) auch Anwendungen mit SSO anbinden, die nicht Windows-basierend sind. Öffnet der Anwender nun z.B. eine Webbasierte Cloud-Anwendung, erkennt diese den Anwender als nicht authentifiziert und sendet den Browser zum IDP. Dieser authentifiziert den Anwender per IWA, per Kennwort, etc. und sendet den Anwender zurück zu der ursprünglich aufgerufenen Anwendung – voila, SSO gleich zweimal.
Wo liegen nun die Unterschiede zum CIAM?
Bei CIAM sind die Anwender Geschäftspartner und Unternehmenskunden oder in manchen Einsatzbereichen auch Einzelkunden (Consumer). Diese sind aber nicht im Active Directory.
Im B2E-IAM, auch Employee Identity genannt, sind die Aufgaben klar verteilt – die IT-Infrastruktur stellt AD und IDP bereit und hilft den Anwendungsverantwortlichen, ihre Anwendungen per OAuth oder SAML an den IDP anzubinden. Der IDP wird zusätzlich für den Anwender die „Seite“ im Browser, auf der sich Sicherheitsmechanismen wie Multifaktor-Authentifizierung oder auch zentrale Dienste wie eine Kennwortrücksetzung befindet – wenn er sie denn jemals sieht (wegen IWA). Alles wird einheitlich.
Wie sieht das nun beim Kunden aus? Die Identitäten sind weder im AD oder sonst abgelegt. Es wird ein Registrierungsprozess benötigt, der insbesondere bei der Zielgruppe „Consumer“ auch von diesem selbst ausgelöst und durchgeführt wird. Damit ist es kosteneffektiv und es gibt keine Wartezeiten.
Und Consumer bringen gerne ihre Identität gern mit z.B. von Apple, Microsoft (Consumer), Facebook, Google und vielen mehr. Wer eine Identität mitbringt, will sich kein weiteres Kennwort merken. Haben wir uns nun im internen IAM Projekt noch um die „Federation“ – da traut ein IDP einem anderen – gedrückt, so ist das im Consumer-IAM nicht zu vermeiden.
Herausforderung 2: Die verschiedenen Ansprechpartner und Verantwortlichkeiten
Viele Unternehmen haben früh mit der Digitalisierung von Partner- und Kundenbeziehungen begonnen. Eine Infrastruktur mit selbstentwickelten CIAM-Komponenten existiert und die meisten Anwendungen sind angebunden. Was vor einigen Jahren noch funktioniert hat, kann heute mit der Benchmark und den Anforderungen des Marktes nicht mithalten. CIAM-Lösungen bieten viele Services serienmäßig und müssen dennoch flexibel und anpassbar sein. Dazu kommen Themen wie DSGVO, die generelle Sicherheit. Dabei stellen sich Fragen, ob die Kennwörter per one-way-Hash sicher oder noch im Klartext der Datenbank gespeichert sind. Denn idealerweise kennen die Unternehmen die Kennwörter gar nicht und hat sie niemals im Klartext in einer JavaScript-Variablen in der Hand gehabt. Bei der Migration der Anwendungen auf der eigenen Webseite in das CIAM, gibt es aber auch noch weitere Herausforderungen. Je nach Stand der Digitalisierung in einem Unternehmen finden sich hier mehr oder weniger Eigenentwicklungen, Produkte, Cloud-Services und mehr. Viele Lösungen haben ihre eigene, oft handprogrammierte Benutzerverwaltung. Die Verantwortung für die Webseite sind aber oft nicht jene, die den technischen Hintergrund gebaut haben. Während die Entwickler bereits in anderen Projekten stecken und damit andere Prioritäten haben, sind die Verantwortlichen der Webseite vom Thema IDP und CIAM puncto Einheitlichkeit durchaus begeistert.
Soll nun eine Anwendung angebunden werden, dann spricht man sehr schnell mit den Entwicklern – einer bunten Mischung aus internen, beinahe-internen und externen Ansprechpartnern. Diese benötigen Unterstützung, um die aktuell im Einsatz befindliche Anwendungsplattform mit einem zentralen Login-Mechanismus zu verbinden. Meist existiert ja bereits etwas, oft auch mehrere Implementierungen, daher wird eine Migration notwendig – und wieder Unterstützung für die Entwickler. Wenn also die Ansprechpartner der Anwendungen bekannt sind, ist zwar die Migration auf eine Standardlösung noch immer nicht ganz einfach, aber bereits die halbe Miete.
Herausforderung 3: Austauschbarkeit bei Produkterneuerungen
Bedürfnisse ändern sich, Produkte entwickeln sich weiter. Das gilt sowohl für CIAM als auch für die angebundenen Anwendungen bzw. Anwendungsplattformen. Daher sind typische Aussagen wie z.B.: „Wir nutzen den IDP von X für die Intranet-Authentifizierung, dann müssen wir auch die CIAM-Lösung von X für das Extranet nutzen“ oder auch „Unsere Extranet-Anwendungsplattform bringt einen Login-Service mit. Das ist der perfekte CIAM-Service für uns“ zu vermeiden.
Der eigentliche Vorteil von IAM und den technischen Komponenten wie z.B. dem IDP, ist die hohe Standardisierung wie SAML, OAuth oder Federation. Wer diese Begriffe in den Vordergrund stellt und Anwendungen darüber sauber an eine CIAM-Infrastruktur anbindet, hat in der Zukunft alle Karten in der Hand. Bei jeder neuen Entwicklung die puncto CIAM-Produkt auf den Markt kommt, kann es dann auch eingesetzt werden, ohne alle Anwendungen neu zu entwickeln. Dasselbe gilt für die Anwendungen und Anwendungsplattformen. Ein Austausch ist nie leicht, aber das CIAM sollte das kleinste Problem dabei sein und bleiben.
Herausforderung 4: Ab in die Cloud auch mit dem CIAM
Kann man Kundenidentitäten zu einem Cloud-IDP bedenkenlos geben? Denn zum einen gibt es sehr gute CIAM-Komponenten, die On-Premises oder in einer Private Cloud implementieren kann. Auch OpenSource Produkte gehören dazu. Zum anderen gilt, wie oben erwähnt, wenn Anwendungsentwickler sich nicht um Kennwörter kümmern müssen, weil sie einfach einen Link zur Login-Seite sowie nach dem Login einen Token mit der User-Identität erhalten, können Fehler vermieden werden. Die Cloud IDPs der verschiedenen Anbieter werden mit hohem Aufwand auf Sicherheit geprüft, und das auf zahlreichen Leveln wie von den Anbietern und diversen regulatorischen Datenschutzbestimmungen. Wenn Probleme erkannt werden, können diese zentral auch gelöst werden, was für die eigenen Infrastruktur leider nicht möglich ist. Aber wie immer gilt, die Entscheidung kann niemandem abgenommen werden – aber das Wachstum der Cloud-CIAM-Lösungen ist nicht zu unterschätzen.
Wir haben für Ihre Herausforderung die passende Lösung
Die IPG hat in diesem Thema bereits zahlreiche Projekte umgesetzt und für Kunden mit genau diesen Herausforderungen zukunftssicheren Lösungen erarbeitet. Sprechen Sie uns gerne an.
Volker Jürgensen startete nach seinem Studium des Wirtschaftingenieurwesens in der Gründerzeit des Internets bei einem kleinen Startup um Banken und anderen Kunden E-Mail- und Internetdienstleistungen bereitzustellen – selbst eine Buch-shop implementierte er selbst vor der Jahrtausendwende. Es folgte ein längerer Beratereinsatz im Ausland bei einem großen Chemieunternehmen und die Basis für eine internationale, technische Tätigkeit war geschaffen – bei Lotus und später IBM hat er Unified Communication- und Collaborationlösungen bei verschiedensten Key Accounts vorgestellt und den Vertriebsprozess unterstützt. Bei den verschiedenen Aufgaben kristallisierte sich immer wieder heraus, dass die Identitäten der Benutzer, deren Authentifizierung und die Berechtigungen wichtig sind – und immer wieder wurde dieses Wissen benötigt. Dann wechselte Herr Jürgensen die Seiten und fokussiert sich nun als Berater im Bereich IAM auf die Unterstützung der Kunden und überbrückt jederzeit die Spanne zwischen Technik und dem Geschäft – mit den vielfältigen, internationalen Erfahrungen versetzt er sich gern in die Position der Beteiligten und spricht ihre Sprache.
Lesen Sie mehr Beiträge von Volker Jürgensen
