SSO mit Client-Zertifikaten

1. Single Sign-On (SSO) Anmeldung

SSO ermöglicht es einem Benutzer, sich mit einem einzigen Passwort bei mehreren angeschlossenen Webportalen und / oder Webanwendungen anzumelden. Dies ist für den Benutzer sehr bequem, da er sich nicht viele Passwörter merken muss. Wenn hier jedoch keine Verschlüsselung stattfindet, hat SSO einen großen Nachteil. Wenn ein Passwort durchgesickert oder geknackt ist, kann ein Angreifer auf alle Websites / Anwendungen zugreifen, die unter diesem Passwort zugänglich sind. Dieser Nachteil ist für die meisten Menschen ein schwerwiegender Grund, SSO nicht zu verwenden.

Es gibt jedoch eine Authentifizierungsmethode, bei der die Portale die Identität der angemeldeten Person bei dem speziellen Authentifizierungsportal-Dienst abfragen. Diese Lösungen sind in der Tschechischen Republik als MyID oder Bank Identity bekannt. Die Anmeldung auf diese Weise gilt als sicher, da der genannte Dienst Kryptographie verwendet, oft indirekt über eine spezielle Anwendung wie den RB-Schlüssel der Raiffeisenbank.

2. Client-Zertifikate

Eine häufige Anwendung eines Client-Zertifikats ist die verschlüsselte Kommunikation. Dabei handelt es sich entweder um den Austausch von E-Mail-Nachrichten oder um die Nutzung einer Website, eines Webportals oder von Webanwendungen mit https-Protokoll.

Um den Browser mit vielen Arten von Webportalen zu verbinden, genügt es, das Stammzertifikat ihrer Zertifizierungsstelle zu besitzen. Die Verbindung basiert dann darauf, dass sowohl Ihr Browser als auch die Website der gleichen Zertifizierungsstelle vertrauen. Außerdem sind die Root-Zertifikate vieler CAs in Browsern bereits vorinstalliert.

Für den Zugriff von Clients (Personen) ist es in der Regel erforderlich, dass diese ihr Client-Zertifikat ausstellen und installieren lassen. Einige Sicherheitsprogramme auf dem Client-Rechner erzeugen eine CSR (Certificate Signing Request) mit einem öffentlichen Schlüssel und einem dazugehörigen privaten Schlüssel. Der Benutzer schickt dann die CSR zur Signatur an die Zertifizierungsstelle und erhält sein Zertifikat. Der private Schlüssel verbleibt auf dem Rechner, auf dem er erzeugt wurde, und wird zum Ent- oder Verschlüsseln (je nach Art der Nutzung) verwendet.

Die Protokolle SSL (Secure Sockets Layer, 1.0, 2.0, 3.0) und TLS (Transport Layer Security, 1.0, 1.1, 1.2, 1.3) werden zur Kommunikation mit Mail- und Webservern (und anderen) verwendet. Aufgrund der Sicherheitslücken der Protokolle und ihrer allmählichen Veralterung werden jetzt die TLS-Versionen 1.2 und 1.3 empfohlen.

3. Kombination von SSO- und Client-Zertifikaten

Das Client-Zertifikat kann als geeignet für die SSO-Anmeldung gekennzeichnet werden. Gemäß dem CAcert-Dokument Certificate Practice Statement (CPS, COD6), Absatz 3.1.1, handelt es sich um einen Hash einer Zufallszahl.

In dem von Oracle zur Verfügung gestellten Dokument heißt es weiter, dass SSO einen Single Sign-On-Server erfordert, der Anfragen von "föderierten" Partnern erhält, bei denen sich die Benutzer-Person anmelden möchte. Der SSO-Server ruft eine Kopie des Benutzerzertifikats aus der Datenbank ab und vergleicht sie mit der Anfrage. Daher muss das Benutzerzertifikat irgendwo gespeichert sein und der SSO-Server muss Zugriff darauf haben.

Vorteile von Certificate-Enabled Single Sign-On

(Oracle, https://docs.oracle.com/cd/A97329_03/manage.902/a96115/pki.htm)

Die Zertifikatsauthentifizierung bietet den Vorteil, dass Partneranwendungen standardmäßig PKI-fähig sind, wenn der Single Sign-On-Server PKI-fähig ist. Wie bei Single Sign-On ohne Zertifikate, verlassen sich diese Anwendungen auf Cookies zur Authentifizierung. Das Abrufen und Überprüfen eines Cookies erfordert weniger Rechenaufwand als die Durchführung eines SSL-Handshakes. Für Webanwendungen, die durch kurzlebige Sitzungen gekennzeichnet sind, führt dies zu einer erheblichen Verbesserung der Serverleistung und des Durchsatzes.

Authentifizierungsoptionen

Oracle Single Sign-On kann für SSL sowohl mit als auch ohne Client-Zertifikate konfiguriert werden. Die erste Option, die serverseitige Authentifizierung, bietet ein hohes Maß an Sicherheit. Dennoch ist das Passwort des Benutzers anfällig für Angriffe - entweder durch Raten oder durch Brute Force. Die zertifikatsbasierte Authentifizierung sowohl auf Client- als auch auf Serverseite erschwert es dagegen, Daten auszuspähen oder zu verändern oder sich als Client oder Server auszugeben.

Authentifizierungsablauf bei zertifikatsbasiertem Single Sign-On

In Abbildung 4-1 ist der Authentifizierungsfluss bei zertifikatsaktiviertem Single Sign-On dargestellt.

Abbildung 4-1 Zertifikatsfähiges Single Sign-On

  1. Der Single Sign-On-Benutzer versucht, auf eine Partneranwendung zuzugreifen.
  2. Die Partneranwendung leitet den Benutzer zur Authentifizierung an den Single Sign-On-Server weiter. Der Server muss so konfiguriert sein, dass er zumindest nach einer optionalen Client-Zertifizierung fragt.
  3. Wenn der Server für SSL konfiguriert wurde, findet der SSL-Handshake statt. Der Browser fordert den Benutzer zur Eingabe eines Passworts auf, das die Zertifikats- und Schlüsseldatenbank des Browsers öffnet. Der Browser sendet dann das Zertifikat des Benutzers an die Anmelde-URL des Single Sign-On-Servers.
  4. Mod_ossl, das SSL-Modul auf dem Single Sign-On-Server, übergibt die Zertifikatsinformationen des Benutzers an ein PL/SQL-Modul, das den Spitznamen des Benutzers und optional seinen Abonnentennamen zuordnet.
  5. Das Zuordnungsmodul übergibt den zugeordneten Benutzernamen und den optionalen Abonnentennamen an ein Authentifizierungsmodul.
  6. Das Authentifizierungsmodul verwendet den zugeordneten Benutzernamen, um das im Verzeichnis gespeicherte Benutzerzertifikat abzurufen; anschließend vergleicht es dieses Zertifikat mit dem von mod_ossl empfangenen Browserzertifikat.
  7. Wenn die beiden Zertifikate übereinstimmen, signalisiert der Single Sign-On-Server, dass die Authentifizierung erfolgreich war, indem er ein URLC-Token, das Benutzerinformationen enthält, an die Anwendung weitergibt.
  8. Die Anwendung leitet den Benutzer an die angeforderte URL weiter, die dann den Inhalt liefert.

Single Sign On Zertifikat-Authentifizierung Übersicht

(VMware, https://code.vmware.com/web/workspace-one/core-capabilities/Single-Sign-On-Certificate-Authentication)

Aus Sicherheitsgründen können Unternehmen eine Authentifizierung für ihre API-Endpunkte und Websites verlangen. SSO über Zertifikate ermöglicht es einem Entwickler, Anmeldeinformationen zu nutzen, um die Authentifizierung zu handhaben, ohne dass der Endbenutzer der App dazu aufgefordert wird.

Integrierte Authentifizierung ist eine SDK-Funktion, mit der ein Entwickler Single Sign On für die Webanfragen seiner App erreichen kann. Die Client-Zertifikate des Benutzers werden automatisch an einen Endpunkt weitergeleitet, der zur Zertifikatsauthentifizierung auffordert. Dadurch ist es für den Entwickler nicht mehr notwendig, die Authentifizierung für einen Endpunkt manuell zu handhaben oder einen Benutzer zur Eingabe von Anmeldeinformationen aufzufordern.

Single Sign-On, SSO

(Wikipedia, https://en.wikipedia.org/wiki/Single_sign-on)

Vorteile

Zu den Vorteilen der Verwendung von Single Sign-On gehören:

SSO nutzt zentralisierte Authentifizierungsserver, die von allen anderen Anwendungen und Systemen zur Authentifizierung verwendet werden, und kombiniert dies mit Techniken, die sicherstellen, dass Benutzer ihre Anmeldeinformationen nicht mehr aktiv eingeben müssen.

Kritik

Der Begriff "Reduced Sign-On" (RSO) wurde von einigen verwendet, um die Tatsache widerzuspiegeln, dass Single Sign-On unpraktisch ist, wenn es darum geht, den Bedarf an verschiedenen Ebenen des sicheren Zugriffs im Unternehmen zu decken, und daher mehr als ein Authentifizierungsserver notwendig sein kann.

Da Single Sign-On den Zugriff auf viele Ressourcen ermöglicht, sobald der Benutzer anfänglich authentifiziert ist ("Schlüssel zum Schloss"), erhöht es die negativen Auswirkungen, falls die Anmeldeinformationen für andere Personen verfügbar sind und missbraucht werden. Daher erfordert Single Sign-on einen verstärkten Fokus auf den Schutz der Benutzer-Credentials und sollte idealerweise mit starken Authentifizierungsmethoden wie Smartcards und Einmal-Passwort-Tokens kombiniert werden.

Single Sign-On macht auch die Authentifizierungssysteme hochkritisch; ein Verlust ihrer Verfügbarkeit kann dazu führen, dass der Zugriff auf alle unter dem SSO vereinigten Systeme verweigert wird. SSO kann mit Session-Failover-Funktionen konfiguriert werden, um den Systembetrieb aufrechtzuerhalten. Nichtsdestotrotz kann das Risiko eines Systemausfalls Single Sign-On für Systeme, auf die der Zugriff jederzeit gewährleistet sein muss, wie z. B. Sicherheits- oder Fabriksysteme, unerwünscht machen.

Darüber hinaus kann die Verwendung von Single-Sign-On-Techniken unter Verwendung von Social-Networking-Diensten wie Facebook Websites von Drittanbietern in Bibliotheken, Schulen oder an Arbeitsplätzen, die Social-Media-Sites aus Produktivitätsgründen blockieren, unbrauchbar machen. Es kann auch zu Schwierigkeiten in Ländern mit aktiven Zensurregimen führen, wie z. B. China und sein "Golden Shield Project", wo die Website des Drittanbieters vielleicht nicht aktiv zensiert wird, aber effektiv blockiert wird, wenn der soziale Login eines Benutzers blockiert ist.

Sicherheit

Im März 2012 wurde in einem Forschungspapier [Rui Wang; Shuo Chen & XiaoFeng Wang. "Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services"] eine umfangreiche Studie über die Sicherheit von Social-Login-Mechanismen. Die Autoren fanden 8 schwerwiegende Logikfehler in hochkarätigen ID-Anbietern und Websites von vertrauenden Parteien, wie OpenID (einschließlich Google ID und PayPal Access), Facebook, Janrain, Freelancer, FarmVille und Sears.com. Da die Forscher die ID-Anbieter und die Websites der vertrauenden Parteien vor der öffentlichen Bekanntgabe der Entdeckung der Schwachstellen informierten, wurden die Schwachstellen korrigiert, und es wurden keine Sicherheitsverletzungen gemeldet.

Im Mai 2014 wurde eine Sicherheitslücke mit dem Namen "Covert Redirect" bekannt gegeben. Sie wurde zuerst unter dem Titel "Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID" von ihrem Entdecker Wang Jing, einem Mathematik-Doktoranden der Nanyang Technological University in Singapur, gemeldet. Tatsächlich sind fast alle [weasel words] Single-Sign-On-Protokolle betroffen. Covert Redirect nutzt Drittanbieter-Clients aus, die anfällig für ein XSS oder Open Redirect sind.

Im Dezember 2020 wurden Schwachstellen in föderierten Authentifizierungssystemen entdeckt, die von Angreifern während der Datenpanne der US-Bundesregierung 2020 ausgenutzt wurden.

Datenschutz

So wie es ursprünglich in Kerberos und SAML implementiert war, bot Single Sign-On den Benutzern keine Wahlmöglichkeit, ihre persönlichen Daten für jede neue Ressource, die der Benutzer besuchte, freizugeben. Dies funktionierte gut genug innerhalb eines einzelnen Unternehmens, wie dem MIT, wo Kerberos erfunden wurde, oder großen Unternehmen, bei denen alle Ressourcen interne Sites waren. Als sich jedoch föderierte Dienste wie Active Directory Federation Services ausbreiteten, wurden die privaten Informationen des Benutzers an angeschlossene Sites gesendet, die nicht unter der Kontrolle des Unternehmens standen, das die Daten des Benutzers gesammelt hatte. Da sich die Datenschutzbestimmungen mit Gesetzen wie der GDPR nun verschärfen, werden die neueren Methoden wie OpenID Connect immer attraktiver; zum Beispiel unterstützt das MIT, der Urheber von Kerberos, nun OpenID Connect.

E-Mail Adresse

Single Sign-On kann theoretisch funktionieren, ohne dass identifizierende Informationen wie die E-Mail-Adresse an die vertrauende Partei (den Credential-Konsumenten) weitergegeben werden, aber viele Credential-Anbieter erlauben es den Benutzern nicht zu konfigurieren, welche Informationen an den Credential-Konsumenten weitergegeben werden. Ab 2019 ist es bei der Anmeldung bei Google und Facebook nicht erforderlich, dass der Benutzer seine E-Mail-Adresse an den Credential-Konsumenten weitergibt. Die in iOS 13 eingeführte Funktion "Anmelden mit Apple" ermöglicht es dem Benutzer, jedes Mal, wenn er sich bei einem neuen Dienst anmeldet, eine eindeutige Relais-E-Mail anzufordern, wodurch die Wahrscheinlichkeit einer Kontoverknüpfung durch den Credential-Konsumenten verringert wird.

Single Sign-On mit Client-Zertifikaten

(SAP, https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/4e/1262e31e3d2287e10000000a15822b/content.htm?no_cache=true)

Verwendung

Der AS ABAP ermöglicht es Ihnen, die Verwendung von Client-Zertifikaten für SSO zu konfigurieren, wenn Benutzer über ein SAP GUI auf das System zugreifen.

Für die SAP-GUI-Authentifizierung mit Client-Zertifikaten wird der Sicherheitskontext für die Authentifizierung von der GSS-API des AS-ABAP-Systems zur Verfügung gestellt. Um die Verwendung von Client-Zertifikaten für SSO zu ermöglichen, muss daher das AS-ABAP-System für die Verwendung von SNC konfiguriert werden.

Integration

Die Verwendung von Client-Zertifikaten für die Anmeldung mit dem SAP GUI nutzt die Public-Key-Kryptografie und die Persönliche Sicherheitsumgebung (PSE) des AS ABAP zur Ermittlung der Benutzeridentität. Die Client-Zertifikatsinformationen werden jedoch nur für die Authentifizierung von SAP-GUI-Benutzern verwendet. Transport Layer Security, die Integrität und Vertraulichkeit der Authentifizierungsdaten wird durch das auf dem AS ABAP verwendete SNC ermöglicht.

Voraussetzungen

Um SAP-GUI-SSO mit Client-Zertifikaten zu aktivieren, müssen die Benutzer über gültige Client-Zertifikate verfügen. SAP-GUI-Benutzer können Client-Zertifikate von einer etablierten Public-Key-Infrastruktur erhalten.

Die SAP-GUI-Client-Computer und die AS-ABAP-Systeme müssen SAP NetWeaver Single Sign-On oder ein externes Sicherheitsprodukt verwenden, das die Erstellung einer persönlichen Sicherheitsumgebung (PSE) ermöglicht. Die Verwendung eines externen Sicherheitsprodukts wird durch Secure Network Communications (SNC) ermöglicht.

Aktivitäten

Um Benutzer und AS-ABAP-Systeme für die Verwendung von SSO mit Client-Zertifikaten zu aktivieren, müssen Sie

  1. Bereiten Sie die zentrale Instanz vor.
  2. SSO auf dem SAP Logon aktivieren.
  3. Importieren Sie die Public-Key-Zertifikate der Benutzer in den AS ABAP.

Bank-Identitätsgesetz

(Bank Identity Bill, https://www.epravo.cz/top/clanky/navrh-zakona-upravujici-podminky-pro-vznik-bankovni-identity-110488.html)

Was ist das Konzept der Bankidentität?

Die Bankidentität wird ein Werkzeug sein, das zur digitalen Verifizierung der Identität von Bankkunden (natürliche und juristische Personen oder deren Vertreter, die natürliche Personen sind) unter Verwendung von Sicherheitsmethoden verwendet wird, die ihr Electronic Banking ermöglichen. Dieses Tool wird auch tschechischen Bürgern und juristischen Personen, die Internet-Banking nutzen, die Möglichkeit bieten, sich mit E-Government-Diensten und Online-Diensten des Privatsektors zu verbinden. Während Bank- und Regierungskunden in der Lage sein werden, digitale Identitäten kostenlos zu verifizieren, werden verschiedene Anbieter digitaler Dienstleistungen Verifizierungsgebühren an Banken und Niederlassungen ausländischer Banken zahlen, um ihre Kunden zu identifizieren. Die Teilnahme von Banken und Niederlassungen ausländischer Banken an dem Projekt wird nicht verpflichtend sein und auf freiwilliger Basis erfolgen.

Zusätzlich zu der Tatsache, dass die vorgeschlagene Verordnung die Öffnung des Marktes für elektronische Identifizierungsdienste ermöglicht, wird es auch eine Änderung in der Funktionsweise des sogenannten Nationalen Punktes für Identifizierung und Authentifizierung (im Folgenden "NIA") in Bezug auf Banken und Zweigstellen ausländischer Banken geben. Damit das Projekt erfolgreich arbeiten kann, regelt der Gesetzentwurf auch den Zugang von Banken und Zweigstellen ausländischer Banken zu den Grundregistern der Tschechischen Republik. Der Zugang wird eingeschränkt, damit die Banken und Zweigstellen ausländischer Banken Geldwäsche und Terrorismusfinanzierung effektiver verhindern können, sowie Fälle verhindern, in denen die Identität der Bank missbraucht werden könnte.

Referenzen

KategorieSoftware

SSO/DE (last edited 2021-04-20 19:29:54 by AlesKastner)