Single Sign-on mit SAML 2.0

Überblick

Security Assertion Markup Language 2.0 (SAML 2.0) ist ein standardisiertes, XML-basiertes Framework für den Austausch von Sicherheits- und Anmeldeinformationen zwischen verschiedenen Systemen. Häufigster Anwendungsfall für die Nutzung dieses Standards ist die Bereitstellung von Single Sign-on (SSO) für Webanwendungen. In CURSOR-CRM kann SAML 2.0 verwendet werden, um den Web Client in eine bestehende Umgebung für Single Sign-on einzugliedern. Dazu wird das Web Browser SSO Profile von SAML 2.0 verwendet. Die beteiligten Systeme tauschen dann so genannte SAML Assertions aus, um Informationen über Teilnehmer in der Servicelandschaft zu kommunizieren.

Die Authentifizierung von Benutzern mit SAML 2.0 ist nur im Web Client möglich. Andere Clients, wie etwa der Windows Client oder die Apps, unterstützen dieses Anmeldeverfahren nicht.

Beteiligte Systeme

Beim Ablauf des SAML 2.0 Web Browser SSO Profile und damit auch bei der Verwendung von SAML 2.0 SSO im CURSOR-CRM Web Client sind drei Parteien beteiligt:

• Identity Provider (IdP): Der Identity Provider führt die Authentifizierung von Benutzern durch. Dazu kann er beliebige Verfahren, wie etwa eine Anmeldemaske mit Benutzername und Passwort oder Kerberos verwenden und diese auch beispielsweise um Maßnahmen wie eine 2-Faktor-Authentifizierung ergänzen.
  Beispiele für Identity Provider sind die Microsoft Active Directory Federation Services (ADFS) und Red Hat Keycloak.

• Service Provider (SP): Der Service Provider empfängt Assertions über Benutzer vom Identity Provider und nutzt die Informationen aus diesen, um die Identität von Benutzern bei der Anmeldung festzustellen. Damit verlässt er sich bei der Authentifizierung auf die Aussagen des Identity Providers. Daher wird ein Service Provider auch als Relying Party bezeichnet.
  Der CURSOR-CRM Web Client fungiert in einer SAML 2.0 Systemlandschaft als Service Provider.

• User bzw. User Agent: Als User oder Benutzer wird im Kontext von SAML 2.0 ein Teilnehmer des Systems bezeichnet, der die Dienste eines Service Providers in Anspruch nehmen möchte. Der User Agent ist im Web-Umfeld der Browser dieses Benutzers.

SAML 2.0 Metadaten

CURSOR-CRM nutzt für die Konfiguration von SAML 2.0 Login SAML 2.0 IdP-Metadaten. Identity Provider stellen mit diesen Metadaten Informationen über sich zum Abruf durch Service Provider bereit. Diese kann ein SP wie CURSOR-CRM dann abrufen, um etwa Informationen über SAML 2.0 Endpoints oder verwendete kryptographische Zertifikate zu erlangen. Damit kann die Konfiguration für den CURSOR-CRM Administrator vereinfacht werden.

Hinweis

Damit CURSOR-CRM für die Authentifizierung und Single Sign-on mit einem SAML 2.0 Identity Provider konfiguriert werden kann, muss dieser Identity Provider seine SAML 2.0 Metadaten über einen TLS-verschlüsselten HTTPS-Endpoint zur Verfügung stellen. Nur so kann die Authentizität und Integrität der übertragenen kryptographischen Schlüssel sichergestellt werden.

Zuordnung von Benutzern des Identity Providers zu CURSOR-CRM Benutzern

SAML 2.0 Identity Provider und CURSOR-CRM haben jeweils getrennte Benutzerverwaltungen. CURSOR-CRM verwaltet Benutzer über Mitarbeiterdatensätze. Diese haben ohne weitere Konfiguration zunächst keinen Bezug zu den Benutzern des Identity Providers. Für die Anmeldung mit SAML 2.0 an CURSOR-CRM ist es daher notwendig, dass eine Zuordnung von Benutzern des Identity Providers zu CURSOR-CRM Mitarbeiterdatensätzen erfolgen kann.

In SAML 2.0 Assertions ist ein Feld namens NameID enthalten. Für NameIDs gibt es verschiedene Formate, die allerdings in CURSOR-CRM alles als einfache Zeichenketten behandelt werden. Ob es sich hierbei um bedeutungslose Zeichenketten, lange Zahlenkolonnen oder strukturierte Daten handelt, ist ein Implementierungsdetail des Identity Providers bzw. kann dort eingestellt werden. Beim Senden der Authentifizierungsanfrage an den Identity Provider übergibt CURSOR-CRM einen Wunsch für das NameID-Format. Standardmäßig wird als Wunsch das Format "Unspecified" übergeben, womit der Identity Provider frei über das Format entscheiden kann. Dies kann jedoch in den CURSOR-CRM Systemeinstellungen auf ein anderes NameID-Format umgestellt werden.

Die Zuordnung dieser NameIDs zu CURSOR-CRM Benutzern erfolgt über das Feld SAML Login Name im Mitarbeiterdatensatz. In dieses Textfeld muss die vom Identity Provider für diesen Mitarbeiter verwendete NameID eingetragen werden. Wenn eine korrekte Anmeldung mit SAML 2.0 am System stattfindet, durchsucht CURSOR-CRM die SAML Login Namen aller Mitarbeiterdatensätze nach dem entsprechenden Wert. Nur dann wenn nur ein einziger Mitarbeiterdatensatz einen SAML Login Namen hat, der exakt mit der NameID der empfangenen SAML 2.0 Assertion übereinstimmt, wird dieser Mitarbeiter dem laufenden Anmeldeversuch zugeordnet und angemeldet. Enthalten mehrere Mitarbeiterdatensätze einen identischen SAML Login Namen, wird die Anmeldung mit SAML 2.0 aus Sicherheitsgründen für beide Mitarbeiter deaktiviert.

NameIDs und damit SAML Login Namen der Mitarbeiter werden entsprechend dem SAML 2.0 Standard als case-sensitive behandelt, das heißt die Groß- und Kleinschreibung ist signifikant. Die NameIDs abcdef123456 und aBCDEf123456 beschreiben also unterschiedliche Benutzer!
Da dies eine häufige Fehlerquelle darstellt, werden jedoch fehlgeschlagene Benutzerzuordnungen, die durch unterschiedliche Groß- und Kleinschreibung zustandegekommen sind, im Server-Log detailliert protokolliert.

Systemeinstellungen

Konfiguration in CURSOR-CRM

In den Systemeinstellungen befinden sich die für SAML 2.0 relevanten Einstellungen im Bereich SAML 2.0 Login. Hier stehen folgende Einstellungen zur Verfügung:

Konfiguration pro CURSOR-CRM Benutzer

Für jeden CURSOR-CRM Benutzer, für den der Login mit SAML 2.0 möglich sein soll, muss im Mitarbeiterdatensatz der korrekte SAML Login Name hinterlegt werden, um Benutzer des Identity Providers den CRM-Benutzern zuordnen zu können. Der korrekte Name hängt von der Konfiguration des Identity Providers ab. Details zur Zuordnung können Abschnitt Zuordnung von Benutzern des Identity Providers zu CURSOR-CRM Benutzern entnommen werden.

Nutzung im CURSOR-CRM Web Client

Allgemeine Hinweise zur Nutzung

Wenn SAML 2.0 korrekt konfiguriert wurde, kann es im CURSOR-CRM Web Client genutzt werden. Dazu muss eine bestimmte Anmeldeseite genutzt werden, da die normale Anmeldeseite anderen Anmeldeverfahren vorenthalten ist. Die SAML 2.0 Anmeldung steht nach vollständiger Konfiguration als Anmeldevariante in der Oberfläche der Login-Maske zur Verfügung.

Tritt bei der Anmeldung mit SAML 2.0 ein Fehler auf, wird der Nutzer automatisch auf die normale Anmeldeseite weitergeleitet. Dort wird dann eine entsprechende Fehlermeldung angezeigt und der Nutzer kann mit einer manuellen Anmeldung fortfahren.

Ist SAML 2.0 im System deaktiviert, erfolgt eine Weiterleitung auf die Anmeldeseite ohne Fehlermeldung.

Zusammenspiel mit anderen Authentifizierungsverfahren in CURSOR-CRM

Die Authentifizierung bzw. Single Sign-on mit SAML 2.0 ist durch die Verwendung einer separaten Anmelde-URL unabhängig vom klassichen Login-Verfahren über die Anmeldemaske im Web Client. Auf der klassischen Anmeldemaske kann weiterhin (je nach Konfiguration) der klassische Login mit Benutzername und Passwort oder Single Sign-on mit Kerberos bzw. SPNEGO verwendet werden.

Auf die Anmeldung im Windows Client oder in den Apps hat die SAML 2.0 Konfiguration keinen Einfluss.

Konfiguration eines SAML 2.0 Identity Providers für CURSOR-CRM

Allgemein

Damit CURSOR-CRM einen Identity Provider zur Authentifizierung nutzen kann, muss dieser zunächst für die Zusammenarbeit mit CURSOR-CRM konfiguriert werden. Die dafür zu setzenden Eigenschaften werden nachfolgend stichpunktartig dokumentiert. Diese Optionen sind bei verschiedenen Identity Providern auf unterschiedliche Art zu setzen. Wie genau dies bei einem speziellen Identity Provider funktioniert, ist der Dokumentation des Identity Providers zu entnehmen. Lediglich für die Microdoft Active Directory Federation Services (ADFS) wird in einem späteren Abschnitt eine exemplarische Anleitung mitgeliefert.

• NameID-Format: Unspecified (im Standard; Das angefragte NameID-Format kann in den Systemeinstellungen verändert werden)
  CURSOR-CRM erfordert kein spezielles NameID-Format, da intern NameIDs als einfache Zeichenfolgen verglichen werden. Einzige Voraussetzung ist, dass sich die einem Benutzer zugeordnete NameID nicht ändert. Daher wird als NameID-Format Persistent empfohlen, da dies diese Anforderung erfüllt. Es ist aber explizit nicht erforderlich, dass die NameIDs zufällig generierte Pseudonyme sind (wie eigentlich für persistent NameIDs gefordert). Daher sind auch abweichende Konfigurationen möglich.

• EntityID bzw. Relying Party Identifier: /login/ also zum Beispiel: https://crm.example.com:18443/login

• Assertion Consumer Endpoint URL, POST-Back URL oder Callback-URL: /login/saml/callback, also zum Beispiel: https://crm.example.com:18443/login/saml/callback

Für die Zusammenarbeit mit CURSOR-CRM ist es erforderlich, dass der Identity Provider die SAML 2.0 Assertion digital signiert. Es ist nicht ausreichend, die gesamte SAML 2.0 Response zu signieren, das Assertion-Element in der Response selbst muss signiert sein.

CURSOR-CRM unterstützt keine verschlüsselten SAML 2.0 Assertions und Responses. Eine optionale Verschlüsselung muss im Identity Provider deaktiviert werden. Für die Sicherheit der Anmeldung ist die digitale Signatur der Assertions ausreichend.

Häufig verwendete Identity Provider

Für einige häufig verwendete Identity Provider stellen wir zusätzlich konkrete Schritt-für-Schritt-Anleitungen bereit. Diese finden sich in den folgenden Abschnitten.