SAP Single Sign-On (SSO) kostenlos für Webanwendungen
In meinem Artikel SAP Single Sign-On (SSO) – kostenlos habe ich beschrieben, wie man Single Sign-On für SAP ABAP konfigurieren kann. In diesem Artikel möchte ich beschreiben, wie ich Sigle Sign-On in einem ABAP System für Webanwendungen, wie z. B. die webgui, konfigurieren kann.
Voraussetzungen
Damit sich Benutzer mittels Zertifikat bei einem Webservice anmelden können, müssen einige Voraussetzungen erfüllt werden. Diese habe ich hier mal zusammengefasst:
- Zertifikat (+ privater Schlüssel) muss dem Anwender vorliegen
- SAP-System muss Zertifikate für die Anmeldung akzeptieren
- Der SAP-Webserver muss dem Zertifikatsaussteller vertrauen
- Der SAP-Webservice muss für die zertifikatsbasierte Anmeldung konfiguriert sein
- Über dem Attribut des Zertifikats muss ein Mapping zum Benutzer erfolgen
- Beim SAP Benutzer muss das gemappte Attribut im Benutzerstamm hinterlegt sein
Windows AD – Benutzerzertifikate automatisch verteilen
Die Konfiguration für das „Certificate Auto Enrollment“ wird über eine Gruppenrichtlinie und dem Zertifikatsservice des Active Directory konfiguriert. In diesem Beispiel ist der Active Directory Server ein Windows 2016 Serversystem.
Gruppenrichtlinie für automatisches Enrollment konfigurieren
Die folgende Konfiguration ist relativ einfach, sollte aber in den Einstellungen gut überlegt sein.
Als Erstes erstellen wir eine neue Gruppenrichtlinie und aktivieren in dieser Policy das „Certificate Autoenrollment“.
Dazu starten wir den Group Policy Management Console (gpmc.msc)
Die Richtlinie ist unter: User Configuration | Policies | Windows Settings | Security Settings | Public Key Policies –> Certificate Services Client – Auto Enrollment zu finden.
Neben der Aktivierung, sollten noch die Haken zum Erneuern und zum Aktualisieren von Zertifikaten gesetzt werden.
Mit „Renew expired certificates“, erneuert die automatische Registrierung Zertifikate, wenn die Zertifikatsvorlagen nicht für die automatische Registrierung eingerichtet sind.
Das sind Vorlagen, die mehrere Signaturen erfordern (z. B. Enrollment Agent) oder die Zertifikatsbetreffsinformationen aus dem Antrag akzeptieren. Darüber hinaus werden mit dieser Einstellung ausstehende Anträge abgerufen, die zur Genehmigung durch den CA-Manager in den Status „ausstehend“ gesetzt wurden.
Durch „Update certificates that use certificate template“ registriert und erneuert das Auto Enrollment Zertifikate auf der Grundlage von Zertifikatsvorlagen, die für das Auto Enrollment eingerichtet wurden. Wenn diese Option nicht aktiviert ist, wird keine dieser Aufgaben während der Aktivierung der automatischen Registrierung durchgeführt.
Diese Konfiguration kann so auch unter „Computer Configuration“ gesetzt werden, wenn Serverzertifikate automatisch erstellt werden sollen.
Zum Abschluss muss dieses GPO noch an die entsprechende GPO gelinkt werden, an der sie wirken soll.
Zertifikatsvorlage konfigurieren und aktivieren
Um die Zertifikate automatisch zu erstellen, benötigen wir ein Zertifikatstemplate. Über certsrv.msc können wir die Vorlagen verwalten. Über das Kontextemenü der „Certificate Templates“ können wir diese verwalten.
Vom vorhandenen Nur-Benutzersignatur-Template ein Duplikat erstellen, damit die ausgelieferten Vorlagen nicht verändert und die Standardeinstellungen nachträglich noch geprüft werden kann. Der Name des Duplikats wird dann über „General“ nach eigenen Namenskonventionen angepasst.
Bei der Konfiguration ist hier gut zu überlegen, wie möchte ich authentifizieren und wie erhöhe ich die Sicherheit.
Die wichtigsten Konfigurationen werden über die Reiter General, Subject Name und Request Handling durchgeführt.
Reiter „General“
Im Reiter „General“ wird die Gültigkeitsdauer und die Veröffentlichung des Zertifikats konfiguriert. Für die Gültigkeitsdauer empfehle ich einen überschaubaren Zeitraum von 3 bis 6 Monaten. Man muss bedenken, dass bei einem Mitarbeiteraustritt, oder bei Namensänderung, dass Zertifikat noch seine Gültigkeit behält und dies nicht erwünscht ist.
Zudem möchte man die Veröffentlichung im Active Directory.
Reiter „Subject Name“
Diese Konfigurationen sind später für das Zertifikatsmapping im SAP-System. Für diesen Artikel soll die Konfiguration per E-Mail-Adresse konfiguriert werden. Denkbar wäre aber auch die Authentifizierung über den Microsoft User Principal Name (msUPN) oder dem Common Name (CN).
Der User Principal Name ist ähnlich der E-Mail-Adresse aufgebaut, ist aber in der Regel mit dem internen Domainname konfiguriert. Es könnte aber auch gleich der E-Mail-Adresse sein. Interessant könnte UPN sein, wenn der Benutzername des UPN dem SAP-Benutzernamen entspricht. Dann könnte man über den Parameter ccl/snc/server_partner_name_x509 nur den „PrincipalOnly“ verwenden (siehe auch unter: Weiterführende Links).
Das „Subject Name Format“ kann entweder nur den „Common Name“ oder den „Fully distinguished name“ verwenden. Ich kann über letzteres im SAP-Systeme einen Filter setzen, der nur eine bestimmte OU-Hierarchie erlaubt. Mehr dazu bei der SAP Konfiguration.
Reiter „Request Handling“
Im Prinzip sind die Standardeinstellungen schon gut. Der private Schlüssel sollte nur in wichtigen Fällen als „exportierbar“ markiert werden. Der private Schlüssel ist Voraussetzung für die Zertifikatsanmeldung. Damit würde ich Benutzern gestatten, dieses Zertifikat auf einem x-beliebigen Rechner zu hinterlegen. Dies sollte vermieden werden.
Mit dieser Konfiguration ist man schon gut aufgestellt. Man hat ein Zertifikat und kann über drei Merkmalen den Benutzer später mit dem SAP-Benutzer mappen.
Benutzerzertifikat prüfen
Wenn die Einstellungen im Active Directory durchgeführt wurden, ist es an der Zeit sich mit (s)einem Windows Benutzer anzumelden und die automatische Zertifikatsausstellung prüfen. (Dieser Benutzer sollte selbstredend die Gruppenrichtlinie für das automatische Zertifikat auch zugewiesen haben.)
Bei diesem Benutzer muss ggfs. beim ersten Anmeldne die Gruppenrichtlinie noch einmal erzwungen werden –> gpupdate /force /target:user.
Über certmgr.msc sollte dann das neue erstellte Zertifikat unter „Eigene Zertifikate“ sichtbar sein und die gewünschten Merkmale aus dem Zertifikatstemplate ausweisen.
Die Eigenschaften des Zertifikats:
Dem gegenübergestellt der AD-Benutzer:
Wenn das Zertifikat automatisch mit den gewünschten Merkmalen ausgestellt wird, kann es daran gehen, diese im SAP ABAP für die Anmeldung zu konfigurieren.
SAP Netweaver AS ABAP konfigurieren
Voraussetzung, dass das SAP-System Zertifikate für die Anmeldung akzeptiert, ist, dass die „Server SSL PSE“ in der Transaktion STRUST konfiguriert ist. Und dies idealerweise von dem gleichen Zertifikatsaussteller signiert ist, wie die Benutzerzertifikate.
In diesem Fall gibt es (bewusst) zwei CAs denen vertraut wird.
Wenn die SSL Server PSE konfiguriert ist, muss für die Akzeptanz von Benutzerzertifikaten grundsätzlich nur der Parameter icm/HTTPS/verify_client konfiguriert werden. Mit dem Wert 1 akzeptiert der Server optional Benutzerzertifikate, springt bei Bedarf aber auf Basic Authentication zurück. Mit dem Wert 2 könnte ich eine zertifikatsbasierte Anmeldung erzwingen, mit 0 komplett deaktivieren.
Dabei muss man im Hinterkopf haben, dass die zertifikatsbasierte Anmeldung vom jeweiligen Webservice und dessen Anmeldemethode abhängt. Im Standard ist diese zertifikatsbasierte Anmeldung eine von mehreren, sodass am Service nichts konfiguriert werden muss.
Da die zertifikatsbasierte Anmeldung nur per HTTPS über einen sicheren Kanal durchgeführt werden kann, sollte man darüber nachdenken gegebenenfalls einen automatischen Redirect von HTTP auf HTTPS durchzuführen.
Der wichtigste Parameter ist aber wahrscheinlich login/certificate_mapping_rulebased. Damit wird das Mapping von Zertifikatseigenschaften zu SAP Benutzer IDs über die TA CERTRULE aktiviert. Im Standard müsste das Mapping für einzelne Benutzer über den View USREXTID in der SM30 durchgeführt werden. Was sehr aufwändig werden kann.
Profilparameter
icm/server_port_1 = PROT=HTTPS, PORT=443$$ , TIMEOUT=60 , PROCTIMEOUT=120
icm/HTTPS/verify_client = 1
login/certificate_mapping_rulebased = 1
# Optional
icm/HTTP/redirect_0 = PREFIX=/, FROM=/sap/bc/*, FROMPROT=http, PROT=https, HOST=$(LOCALHOSTFULL),PORT=443$$
Zertifikatsregeln für automatische Anmeldung erstellen – TA CERTRULE
Die Transaktion CERTRULE hilft einem per Wizard und vorhandenem Zertifikat Regeln für das Mapping zu erstellen. Ohne vorhandenen Zertifikat ist das nicht möglich!
Damit die erste Regel erstellt werden kann, das Benutzerzertifikat laden. Dazu rechts vom „Subject“ Feld auf den Auswahlbutton klicken und das Benutzerzertifikat angeben.
Im rechten Feld kann man zwei wichtige Informationen ablesen: 1. gibt es eine Regel für dieses Zertifikat (Mapping Status) und 2. wird ggf. über die Regel ein Benutzer gemapped.
Zur Erstellung der ersten Regel auf den entsprechenden Button drücken, damit wird das Zertifikat analysiert und es stehen 4 Filterkriterien zur Verfügung.
Über den Zertifikatseintrag wählt man, über welches Feld das zu mappende Attribut kommen soll. Über das Feld Subject (Antragssteller) oder Subject Alternative Name (Alternativer Antragsstellername). Über das Feld Subject wäre der Common Name wählbar. Darüber einen SAP Benutzernamen zu mappen wird aber wohl schwierig.
Der Subject Alternative Name mit den Zertifikatsattributen rfc822Name und msUPN kann aber perfekt mit Login As und der E-Mail-Adresse gemapped werden. Alternativ zur E-Mail-Adresse kann auch die SAP Benutzer ID oder der Alias für die Anmeldung konfiguriert werden.
Zu guter Letzt kann man über den Subject Filter den Personenkreis einschränken oder setzen, der mit dieser Regel automatisch angemeldet wird. Wenn man dies gar nicht möchte, kann man im Zertifikatstemplate statt des Fully Distinguishedname den Common Name setzen lassen.
Im oben gezeigten Beispiel ist der Distinguished Name: „CN=Andy Niemann, OU=Benutzer, OU=User, OU=ORG, DC=testlab, DC=local“.
Mit dem oben verwendeten Filter könnten sich mit dieser Regel alle Benutzer in der AD-Struktur „OU=Benutzer, OU=User, OU=ORG, DC=testlab, DC=local“ mit einem Zertifikat anmelden. Möchte ich allen Benutzer in der „OU=User“ ermöglichen sich per Zertifikat anzumelden, muss ich im Subject Filter nur den Eintrag „OU[4],“ entfernen. Statt „OU=Benutzer“ steht dann in der Regel „CN=*,OU=*,OU=User …“.
Wenn dann die Regel angelegt und gespeichert wurde, kann man anhand des Zertifikats gleich prüfen, ob a) eine Regel zu diesem Zertifikat existiert und b) ob dann auch ein passender SAP Benutzer gefunden wird. Es wird übrigens auch angezeigt, wenn die E-Mail-Adresse mehrfach vorhanden ist (Stichwort Testbenutzer).
Automatische Zertifikatswahl im Browser
Damit für die Benutzer, die Anmeldung mittels des Zertifikats automatisch durchgeführt wird, kann man für den Edge oder den Chrome Browser einen entsprechenden Registry Key setzen.
Dazu muss der Key AutoSelectCertificateForUrls z. B. unter [HKLM]SOFTWARE\Policies\Microsoft\Edge\ angelegt werden. Unterhalb dieses Zweigs können dann fortlaufende Reg_SZ Einträge mit den Namen 1,2,3 … angelegt werden.
Bei den Werten kann man auf Muster bei der URL, dem Zertifikatsaussteller oder dem Subjekt des Zertifikats filtern. Zu beachten ist dabei, dass Platzhalter nicht zur Suche nach Übereinstimmungen mit Teilen von Schemas, Domains, Hosts, Ports oder Pfaden verwendet werden können!
Das bedeutet, dass zum Beispiel nicht auf den Pfad /sap/bc/* gefiltert werden kann. Schade eigentlich.
Registry Beispiele für „AutoSelectCertificateForUrls“
Folgende Beispiele zeigen die Möglichkeiten und Anwendungsbeispiele
{"pattern":https://*,"filter":{}}
Mit diesem Beispiel wird grundsätzlich auf jeder HTTPS Seite automatisch das Zertifikat übermittelt. Es besteht nur ein Filter auf das HTTPS-Schema. Sollten mehrere Zertifikate zur Verfügung stehen, kommt ein Pop-up-Fenster mit einer Auswahlliste hoch.
{"pattern":https://[*.]testlab.local:*/*,"filter":{}}
Mit diesem Eintrag setzen wir Wildcards für Hosts und Subdomains ([*.]) in der Domain testlab.local. Bei den Ports wird auch eine Wildcard gesetzt. Der Pfad wird hier generisch freigegeben.
{"pattern":https://[*.]testlab.local:*/*,"filter":{"ISSUER":{"CN":"Testlab-CA", "DC": "testlab", "DC": "local"}}}
In diesem Beispiel kommt jetzt erstmals ein Filter auf das Zertifikat zum Einsatz. Sinnvollerweise werden nur Zertifikate verwendet, die von der internen CA ausgestellt wurden.
{"pattern":https://[*.]testlab.local:*/*,"filter":{"ISSUER":{"CN":"Testlab-CA", "DC": "testlab", "DC": "local"},"SUBJECT":{"OU": "cert-user", "OU": "user", "DC": "testlab", "DC": "local"}}}
SAP Netweaver AS JAVA
Bei SAP AS Java Systemen sind die Profilparameter prinzipiell die gleichen wie bei einem SAP ABAP System (siehe hier). Wir benötigen nur den ABAP-spezifischen Parameter login/certificate_mapping_rulebased nicht.
Die folgende Konfiguration setzt einen bereits fertig konfigurierten HTTPS Service voraus. Dabei wird die Konfiguration im AS Java Netweaver Administration durchgeführt.
Im ersten Schritt wird im Menü Authentifizierung und Single Sign-On das Zertifikatsmapping konfiguriert. Anschließend wird die Konfiguration im Menü SSL abgeschlossen.
Zertifikatsanmeldung konfigurieren
Im Menüpunkt Authentifizierung und Single-On wird die Konfiguration in der Standardrichtlinie ticket und dem Login Modul ClientCertLogin vorgenommen.
Sollten die Module noch nicht vorhanden sein, sollten sie als Erstes in dieser Reihenfolge hinzugefügt werden: EvaluateTicket (Sufficient), ClientCertLogin (Optional), CreateTicket (Sufficient), BasicPasswordLogin (Requisite), CreateTicket (Requisite).
Diese Anordnung prüft erst einmal auf ein gültiges Logon Ticket, bietet optional eine zertifikatsbasierte Anmeldung an und fällt im Fehlerfall auf eine Kennwortbasierte Anmeldung zurück und erstellt bei erfolgreicher Anmeldung ein Ticket.
Die Regeln für die zertifikatsbasierte Anmeldung und dem automatisierten Benutzermapping, finden über Regeln im ClientCertLogin Modul statt.
Zum Hinzufügen von Einträgen muss die Richtlinie ticket über „Bearbeiten“ freigegeben werden.
Dann können zum Beispiel folgende Regeln erstellt werden.
issuer CN=winsvr16,DC=testlab,DC=local
#msUPN
Rule1.AttributeName OID=1.3.6.1.4.1.311.20.2.3
Rule1.getUserFrom expertMode
Rule1.OID 2.5.29.17
Rule1.UserMappingMode Email
#RFC822
Rule2.AttributeName rfc822Name
Rule2.getUserFrom expertMode
Rule2.OID 2.5.29.17
Rule2.UserMappingMode Email
#User Certificate
Rule3.getUserFrom wholeCert
Rule3.filterIssuer CN=another-server,DC=domain,DC=intra
Mit der OID 2.5.29.17 wird der Zertifikatseintrag SubjectAlternativeName angesprochen. Darin wird dann das Attribut per Name z. B. rfc822Name oder im Falle vom User Principal Name per OID gewählt und automatisch auf die E-Mail-Adresse des Benutzers gemapped.
Die Regel 3 sorgt hier für die Möglichkeit manueller Zertifikatsmappings. Dem Benutzer muss dafür im Benutzerstamm (s)ein Zertifikat hinterlegt werden. Das kann zum Beispiel für Service-Benutzern oder Benutzern von Dienstleistern nützlich sein, die kein automatisches Zertifikat bekommen.
SSL-Service Konfiguration
Zum Abschluss muss der SSL-Service noch angepasst werden. Zum einen muss sichergestellt werden, dass die Client-Authentifizierung auf „Anfordern“ steht. Diese sollte eigentlich schon durch den Profilparameter icm/HTTPS/verify_client konfiguriert worden sein.
Wichtiger ist, dass im Reiter „Vertrauenswürdige CAs“ die Zertifikatskette (Root-CA und ggf. Sub-CA) hinterlegt ist. Erst damit werden dem Browser die akzeptierten CAs (und deren ausgestellten Zertifikate) übermittelt.
Viel Erfolg bei der Umsetzung und zufriedenen Anwendern!
Weiterführende Links
Windows 2012 R2 – Certificate Deployment for Users
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies#autoselectcertificateforurls
https://chromeenterprise.google/policies/url-patterns/
Using X.509 Client Certificates on the AS Java
2338952 – CommonCryptoLib 8.5: Configuration Profile Parameters