Die Integration zwischen der Microsoft- und der SAP-Welt stellt viele Unternehmen vor große Herausforderungen. Die verschiedenen Systeme sollen nicht nur miteinander kommunizieren, sondern auch Daten teilen, weitergeben und prozessieren. Eine besonders herausfordernde Aufgabe ist die Integration von Identitäten: Wie kann ich eine Identität zwischen SAP- und Microsoft-Systemen verwalten, ohne dass die User mehrere Accounts oder verschiedene Passwörter nutzen müssen?
In On-Premise-Systemen werden dafür gängige Single-Sign-On-Lösungen wie SAP Single Sign-On (SSO), Microsoft Active Directory Federation Services (ADFS) oder Ping Identity verwendet. Zudem kommen technische Hilfsmittel wie Kerberos Tokens, SAP-Tickets oder X.509-Zertifikate zum Einsatz. Tatsächlich verfügen viele Unternehmen im On-Premise-Bereich bereits über Lösungen, mit denen sie ihren Mitarbeitern ein Single Sign-On über Technologiegrenzen hinweg anbieten können.
In der Cloud stößt man diesbezüglich jedoch schnell an Grenzen. Selten sind Kerberos-Infrastrukturen außerhalb des Unternehmensnetzwerks erreichbar. Mobile Geräte und BYOD-Richtlinien machen Zertifikatsverteilungen zunehmend kompliziert. Gleichzeitig wird die Frage nach einem Single Sign-On in der Cloud immer wichtiger. Geradezu essenziell ist sie in Cloud-Systemen, die eingebettete Drittsysteme ansprechen. Denken Sie beispielsweise an ein S/4HANA-System in der Cloud, das SAP Cloud Analytics Reports anbieten soll.
Hierfür bietet SAP einen Identity Provider (SAP Identity Authentication Service) im Bundle mit seinen Cloud-Produkten an. Allerdings beginnt die Standard-Konfiguration in diesem Fall wieder bei null: Man muss einen Benutzerstamm pflegen, den Benutzern neue Passwörter hinterlegen und die Benutzerverwaltung im Allgemeinen in den Griff bekommen. Der Setup- und Verwaltungsaufwand bei einem solchen Szenario ist gewaltig. Darüber hinaus erhalten User ein neues Initialpasswort, das sie idealerweise nach ihrem Microsoft-Passwort setzen, um ein Gefühl von Single Sign-On zu schaffen. Es ist jedoch kein „echtes“ SSO: Wird im Active Directory das Passwort zurückgesetzt, bleibt in der SAP Cloud das alte bestehen.
Eine Möglichkeit, um viele der skizzierten Hürden zu überwinden, ist es, seinen Benutzerstamm im Active Directory weiterzuverwenden. Hierbei wird das Active Directory des Unternehmens an den SAP Identity Authentification Service (IAS) als Backend-System angebunden.
Der Vorteil: Weder muss man User manuell verwalten, noch gibt es Schiefstände bei den Passwörtern. Der User meldet sich ganz bequem mit seinem Windows-Account an und kann direkt loslegen. Ein weiterer Nutzen: Die Gruppenzuweisungen im Active Directory werden übernommen. So lässt sich die Rechteverwaltung an das Active Directory delegieren – ganz ohne zusätzliches Customizing.
Nicht alle Identitäten landen zwangsläufig im Active Directory. Immer mehr Unternehmen bieten Kundenportale im B2B- oder B2C-Kontext an. Das Ziel: Kunden oder Lieferanten sollen mit einer zentralen Identität Zugang zu allen Services und Apps haben. Im Kontext der Identitäten wirft das viele Fragen auf: Wie kommt ein Kunde zu seinem Account? Wie stelle ich die Isolation von Kunden-Accounts sicher? Wie kann ich sichergehen, dass Unbefugte keinen Zugriff auf unternehmensinterne Systeme haben? Gibt es Restriktionen bezüglich der Zugriffe aus bestimmten Ländern oder Regionen (wegen Handelsrestriktionen oder Ähnlichem), die ich beachten muss?
SAP Cloud Identity bietet Mechanismen zur Selbstregistrierung sowie zur Steuerung und Isolation von externen Identitäten. Der Zugriffsmechanismus funktioniert bei einem angebundenem Active Directory mit einer Fallback-Funktionalität. Dabei wird primär bei einer Anmeldung im Active Directory nach dem Account gesucht. Wird er nicht gefunden, sucht das System die Identität im eigenen Benutzerstamm. Das heißt, dass sich externe User, die man nicht im Active Directory pflegen möchte, im IAS verwalten lassen. Natürlich werden nur die Gruppen eingelesen, die der User im IAS zugewiesen bekommen hat.
Der IAS bietet sogar eine Selbstregistrierungsfunktion, die fein granular steuerbar ist – sei es mit einer Seite im Corporate Identity, mit einem Zugriffsschutz aus bestimmten Regionen oder mit dem Setzen von eigenen AGBs. User, die über solche Quellen kommen, erhalten einen eigenen isolierten User-Bereich (in diesem Fall „public“) und können nur Systeme ansprechen, die explizit erlaubt wurden. Außerdem können die User ganz bequem die Passwort-vergessen-Funktionalität von SAP Cloud Identity nutzen, um ihre Passwörter zurückzusetzen. Zusätzlich stellt das IAS Schnittstellen bereit, um die User über Protokolle wie REST oder SCIM auszulesen, sie auf weitere Systeme zu verteilen oder Analysen und Reports zu erstellen.
Oft haben Unternehmen schon eine funktionierende Cloud-SSO-Lösung in der Azure-Cloud in Form des Active Directory Federation Service (ADFS). Viele Funktionalitäten, die der IAS anbietet, beherrscht auch der Counterpart aus der Microsoft-Welt. Daher stehen Unternehmen vor der Frage, ob eine Doppellösung überhaupt Sinn macht. Die Versuchung, eine der Lösungen über das ganze Technologieumfeld hinweg zu nutzen, ist natürlich groß. Insofern ist die Frage nach der Sinnhaftigkeit nicht gänzlich von der Hand zu weisen.
Die Antwort darauf ist nicht technischer, sondern fachlicher Natur. Wie gut ist die interdisziplinäre Zusammenarbeit meiner Microsoft- und SAP-Kollegen? Welche Aufwände, Bottlenecks und Probleme verursache ich bei einem solchen Zusammenspiel? Wie gehe ich mit Verantwortungen um? Wer ist zuständig, wenn sich ein User auf einem SAP-System mit seinem ADFS-Account nicht anmelden kann? Wer macht die Fehleranalyse? Habe ich Kompetenzen im Unternehmen, die zwischen den beiden Welten nach Fehlern schauen können?
Wer sich nicht ganz sicher ist, ob er die fachlichen Hürden überwinden kann, hat auch die Möglichkeit einer Hybridlösung zwischen IAS und ADFS. Dabei wird eine Art Proxy-Funktionalität des IAS genutzt. Man schließt den IAS einmal an das ADFS an und alle SAP-Systeme, für die Single Sign-On möglich sein soll, werden an den IAS angebunden. Dieser lotst die Authentifizierung dann an das ADFS. Das erhaltene Authentifizierungs-Ticket ist sogar zwischen Microsoft- und SAP-Systemen gültig.
In diesem Fall kann die interne SAP-IT ihre Landschaft an den IAS anbinden und die Funktionalitäten des ADFS nutzen, ohne dass sie jedes Mal die Microsoft-IT einbinden muss. Die Fehleranalyse erfolgt dann primär am IAS. Erst wenn eine Ursache im IAS ausgeschlossen werden kann, kommt die Microsoft-IT ins Spiel. Eine solche technologische Partnerschaft beider Lösungen erhöht die Flexibilität und die Effizienz der IT – trotz eines vermeintlich redundanten Doppelbetriebs.
Dank neuester Technologien ist eine enge Integration zwischen der Microsoft- und der SAP-Welt beim SSO in der Cloud kein unüberwindbares Hindernis mehr. Ob mit einer bestehenden ADFS-Lösung oder mit einem initialen Kick-off mit IAS und AD-Backend – einer Zusammenarbeit von Microsoft- und SAP-Systemen steht nichts mehr im Wege.