CBA (certifcate-based authentication): Warum dieses Feature im neuen Edge Browser so nützlich ist
Bei Verwendung von CBA (certificate-based authentication) können sich Benutzer mithilfe eines Clientzertifikats authentifizieren. Das Zertifikat wird anstelle des Benutzernamens und Kennworts verwendet. Durch die Verwendung der zertifikatbasierten Authentifizierung können Administratoren ihren Benutzern den Zugriff auf SAP und Non-SAP Ressourcen ermöglichen, ohne dass Anmeldeinformationen eingegeben werden müssen. So weit so gut!
Ich hatte in meinen SAP-Security-Projekten in der Vergangenheit schon häufiger den Fall, dass sich während (und manchmal auch nach) der Einführung von SAP Single Sign-On auf Basis von X.509 Zertifikaten, folgendes bestimmtes Problem ergab:
- Die Clients des Unternehmens melden sich mit einem TLS-Client-Zertifikat bei SAP an.
- Durch den SAP Secure Login Server werden dazu temporäre Zertifikate ausgestellt.
- Der Secure Login Server wird als Sub CA 1 zur vorhandenen Corporate Root CA betrieben.
- Zur Absicherung der WLAN-Infrastruktur (802.1x EAP-TLS) stellt das Unternehmen den Anwendern nun ein weiteres Benutzer-Zertifikat per Auto-Enrollment bereit.
- Aussteller dieses WLAN-Zertifikats ist die Sub CA 2 der vorhandenen Corporate Root CA.
- Beide Zertifikate enthalten aufgrund deren Anforderungen die erforderlichen Eigenschaften für eine TLS-Client-Authentifizierung, insbesondere die EKU „Client Authentication“.
Da haben wir den Salat!
Beim Client ergibt sich aus dieser Situation ein Usability-Problem, das sehr unschön werden kann. Beide Zertifikate akzeptiert der Browser – oder um genau zu sein der TLS fähige Webanwendungsserver – als verwendbares TLS-Client-Authentifizierungszertifikat. Öffnet der Anwender nun beispielsweise sein Fiori Launchpad, erscheint ein Auswahldialog. Erschwerend kommt meist dazu, dass die beiden Zertifikate im Auswahldialog nur schwer zu unterscheiden sind. Problematisch wird es dann, wenn der SAP-Anwender nun (versehentlich) sein WLAN-Zertifikat verwendet, und schon erscheint ungewollt der Anmeldebildschirm.
Das Problem habe ich im Mai 2019 in einem Blog beschrieben und auch mögliche Lösungen dazu. Den Blog findet Ihr hier.
Damals konnten wir keine Lösung finden, um die Zertifikatsauswahl über einen Browser (Internet Explorer, Chrome) einzuschränken bzw. zu steuern. Der neue Browser Microsoft Edge Browser basiert auf Chrome und wurde im Januar 2020 veröffentlicht. Diese Version lässt sich mittels Richtlinien (GPO) konfigurieren.
An sich nichts berauschend Neues, aber das hat mich auf die Fährte gebracht. Hintergrund war auch hier ein Kundenprojekt, wobei das Unternehmen hier ein zentrales TLS-Client-Authentifizierungszertifikat nutzte. Doch der neue Edge Browser ist da etwas „zickig“ und verlangt, dass eine bestimmte Policy AutoSelectCertificateForUrls aktiv konfiguriert wird, ansonsten wird für keine Site eine automatische Auswahl durchgeführt. Dieses nette Feature liefert uns also die Lösung für unser Problem. Basierend auf URL-Mustern kann der Microsoft Edge Browser für eine Liste von Websites automatisch das korrekte Client-Zertifikat auswählen, wenn die Site eines anfordert, herrlich! ?
Ich lasse Euch mit diesem Blog an meinen Erkenntnissen teilhaben, vielleicht stößt ja auch jemand beim Googlen nach einer Lösung auf diesen Blog!
Table of Contents
Der Testaufbau
Clientsystem: Windows 10 Client PC
Bereitstellung eines Benutzerzertifikats im Windows-Zertifikatsspeicher
Das Zertifikat wurde von einem SAP Secure Login Server ausgestellt, dies spielt jedoch keine Rolle, da die hier gezeigten Vorgaben mit allen Zertifikaten funktionieren.
Zielsystem: SAP NW AS ABAP
URL: https://icm.sapnwsso.local:50444/sap/bc/gui/sap/its/webgui?sap-client=001&sap-language=DE
Das Zielsystem ist für die Authentifizierung mit Client Zertifikaten konfiguriert.
Benutzerzertifikat: CN=COLT, OU=Demo, O=Xiting GmbH, C=DE
Das nachgestellte Problemverhalten
Sobald die URL aufgerufen wird, erscheint am Edge die Zertifikatsauswahl, obwohl nur ein passendes Zertifikat vorhanden ist.
Ganz genau, an exakt dieser Stelle würden im Problemfall jetzt alle passenden TLS-Zertifikate angezeigt werden und der Benutzer müsste die Auswahl treffen.
Technischer Hintergrund der Policy – Beschreibung von Microsoft
AutoSelectCertificateForUrls
Policy Name: AutoSelectCertificateForUrls
Description: Automatically select client certificates for these sites
Policy Path: Microsoft Edge\Content settings
Compatibility: Microsoft Edge version 77 Windows 7 or later
Machine: Yes | HKLM\Software\Policies\Microsoft\Edge\AutoSelectCertificateForUrls
User: Yes | HKCU\Software\Policies\Microsoft\Edge\AutoSelectCertificateForUrls
Specify a list of sites, based on URL patterns, for which Microsoft Edge should automatically select a client certificate, if the site requests one.
The value must be an array of stringified JSON dictionaries. Each dictionary must have the form { „pattern“: „$URL_PATTERN“, „filter“ : $FILTER }, where $URL_PATTERN is a content setting pattern. $FILTER restricts from which client certificates the browser will automatically select.
Independent of the filter, only certificates will be selected that match the server’s certificate request. For example, if $FILTER has the form { „ISSUER“: { „CN“: „$ISSUER_CN“ } }, additionally only client certificates are selected that are issued by a certificate with the CommonName $ISSUER_CN.
If $FILTER contains an „ISSUER“ and a „SUBJECT“ section, a client certificate must satisfy both conditions to be selected. If $FILTER specifies an organization („O“), a certificate must have at least one organization which matches the specified value to be selected. If $FILTER specifies an organization unit („OU“), a certificate must have at least one organization unit which matches the specified value to be selected. If $FILTER is the empty dictionary {}, the selection of client certificates is not additionally restricted.
If you don’t configure this policy, auto-selection isn’t done for any site.
EXAMPLES
SOFTWARE\Policies\Microsoft\Edge\AutoSelectCertificateForUrls\1 = {„pattern“:“https://www.contoso.com“,“filter“:{„ISSUER“:{„CN“:“certificate issuer name“, „L“: „certificate issuer location“, „O“: „certificate issuer org“, „OU“: „certificate issuer org unit“}, „SUBJECT“:{„CN“:“certificate subject name“, „L“: „certificate subject location“, „O“: „certificate subject org“, „OU“: „certificate subject org unit“}}}
Konfiguration Microsoft Edge mittels Richtlinien
Download der ADMX-Templates für Edge
Infos z. B. hier: https://www.prajwaldesai.com/admx-templates-for-microsoft-edge/
Erstellen einer neuen GPO
Konfigurierte Regel: {„pattern“:“https://icm.sapnwsso.local“,“filter“:{„ISSUER“:{„CN“:“SSO3 SLS User-CA“}, „SUBJECT“:{„O“: „Xiting GmbH“}}}
Ergebnis: Das User-Zertifikat muss O=Xiting GmbH beinhalten und von der Issuing CA SSO3 SLS User-CA ausgestellt worden sein.
Finaler Test am Client
Anwenden der Policy
Kontrolle der Policy
Test 1: Aufruf einer anderen Website für welche keine Policy existiert.
Ergebnis: Zertifikatsauswahldialog (!)
Test 2: Aufruf der gewünschten Website
Ergebnis: Automatische Anmeldung (!)
With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.
Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.
Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.
- Cloud-Integration leicht gemacht: Xiting Central Workflows (XCW) trifft auf SAP Cloud - 30. Juli 2024
- Von Wehmut und Vorfreude: Das bevorstehende Ende von SAP IDM - 20. März 2024
- 2024 SAP Cloud Identity Services & IAM Portfolio: Was ist neu? - 26. Februar 2024
