eIAM Glossar

eIAM ist ein Service des Standarddienstes IKT-Standarddienst Identitäts- und Zugangsverwaltung (IAM-Bund).

Die Marktleistung eIAM steuert den Zugriff auf Webanwendungen, native Mobile-Apps und Webservices der Bundesverwaltung und schützt diese vor unerlaubtem Zugriff.

eIAM föderiert die elektronischen Identitäten unterschiedlicher interner und externer Identitätsprovider zu Verbundsidentitäten zuhanden der Zielapplikationen und setzt die geforderte Authentisierungsstärke durch. eIAM ermöglicht den Single Sign-On (SSO) über mehrere Applikationen.

Optional kann eIAM den angeschlossenen Applikationen Aussagen zu den Berechtigungen der User übermitteln. Das sogenannte Accessmanagement (Zugriffsverwaltung).

Identités dans eIAM et unités, profils et rôles

Der Bundestrustbroker BTB ist die Schaltzentrale von eIAM, über welche alle Authentisierungs-Anfragen und Authentisierungs-Ergebnisse vermittelt werden.

Alle Komponenten von eIAM, sowohl zentrale als auch kundenspezifische, werden sukzessive und gestaffelt auf die neue CI/CD (Continous Integration / Continous Deployment) Betriebsplattform migriert. Diese containerbasierte Betriebsplattform hilft uns eIAM besser zu skalieren und den Anforderungen bezüglich Integrationen und Weiterentwicklung im Service eIAM auch in der Zukunft nachzukommen.

Secure Reverse Proxy für Web Applikationen in den Netzen der Bundesverwaltung mit erhöhten Schutzanforderungen (z.B. SZ+ BIT). Der RP-PEP bildet den Zonenübergang und stellt sicher, dass nur Requests von berechtigten Benutzern an die Applikation in der Spezialzone gelangen. Für dieses Pattern ist zwingend die Bewirtschaftung mindestens einer grobgranularen Rolle (Applikation.ALLOW) im eIAM-AM Access Management erforderlich, welche den generellen Zugriff auf Ressource freigibt.

Web Applikationen, welche aufgrund ihrer Schutzanforderungen nicht in Netzen mit erhöhten Schutzanforderungen betrieben werden (z.B. SZ oder komplett ausserhalb der Netze der Bundesverwaltung), benötigen keinen RP-PEP. Solche Anwendungen föderieren direkt mit dem eIAM-Trustbroker (BTB). In der Vergangenheit wurden Anwendungen über eine zusätzliche Föderationskomponente STS-PEP angebunden. Bestehende Anwendungen werden schrittweise auf das Integrationspattern ohne «STS-PEP» migriert.

In eIAM gibt es nur einen Root Account pro authentifizierte Identität eines Benutzers. In den Root Accounts werden die Stammattribute der Benutzers geführt.

Ein Access Client ist ein dedizierter Arbeitsraum für die Rechtevergabe, optional unterteilbar in Units zwecks Delegation der Rechtevergabetätigkeiten in diesen nach intern oder extern. Der Schnitt eines Access Client ist dem Fach überlassen, der häufigste Schnitt ist 1 Verwaltungseinheit (Amt) = 1 Mandant. Für Grossprojekte oder Applikationen mit Middleware-Charakter kann die Formel 1 Mandant pro Grossprojekt resp. Middleware sinnvoll sein.

In den Access Accounts werden den Benutzern Rechte für Zielapplikationen zugewiesen. Der Access Account fungiert somit als dedizierter Datenraum für Berechtigungen, meistens mit dem Fokus Amt (Access Client).

Eine Identitätsreferenz ist ein Verweis oder auch Zeiger auf die eigentliche Identität eines Subjekts. eIAM arbeitet mit solchen Identitätsreferenzen. Hierbei wird die eigentliche Identität vom jeweiligen Provider der Identität administriert. Beispiele hierfür sind das Active Directory oder die Admin PKI, welche die Identitäten des Benutzers und die Authentisierungsmittel verwaltet.

An den Standard Dienst eIAM angeschlossener Identity Provider. eIAM vermittelt von verschiedenen internen und externen Identitätsprovider (IdPs) Authentisierungsleistungen an Applikationen der Bundesverwaltung. Diese Identitätsprovider werden in drei Gruppen eingeteilt.

• Interner IdP: FED-LOGIN
  
• Externe Dritt-IdPs
  • IdP Gruppe: "BYOI" (Bring Your Own Identity) z.B. AGOV das neue CH-LOGIN, Kantonale-IdPs, edu-ID u.a.
    
  • IdP Gruppe: "Sektor-IdPs" z.B. HIN, ELCA, V-LOGIN u.a.

Mit der Aktivierung des Consistency-Checker werden nun alle Benutzer Stammdaten zwischen Root Account und Access Account, auch bei unabgeklärten elektronischen Identitäten, automatisch nachgeführt d.h. synchronisiert

Qualität der Authentifizierung (QoA)

Erstmalige Verwendung der Applikation für neue User.

Im Rahmen des Zugriffsantrags kann ein Nutzer für eine dedizierte Identität den Zugriff auf eine Fachapplikation beantragen. Sofern diese Identität im entsprechenden Accessmandanten noch nicht vorhanden ist, wird diese Identität dort angelegt und auf die Identität im entsprechenden IdP referenziert. Im Rahmen des Zugriffsantrags werden der Identität die für seine Arbeit in der Applikation benötigten Rollen zugewiesen.

Wenn Sie einen MIO Code (Mobile ID-Onboarding Code) von Ihrem Fachkontakt in der Bundesverwaltung erhalten haben, verwenden Sie diesen, um Ihre Mobile ID* mit der Bundesverwaltung (eIAM) zu verbinden.

Wie der Name schon sagt, handelt es sich beim Pattern "Authentication Only" um den Bezug von reinen Identitäts- und Authentisierungsinformationen durch die Applikation. Die Applikation verzichtet bei "Authentication Only" auf jegliche Art von Autorisierung und Identitätsbewirtschaftung in eIAM. Dies, weil die Applikation gar keine Autorisierung benötigt, oder die Autorisierung komplett selbst (ausserhalb von eIAM) regelt.

Das Pattern bietet sich an für Integrationen, welche nur Authentifizierung durch eIAM benötigen, jedoch keine Grobautorisierung und keine Bewirtschaftung von Identitäten in einem eIAM Access Mandanten. Aus diesem Grund ist «Authentication Only» nicht mit «eIAM RP-PEP» kombinierbar.

eIAM liefert im Anschluss an die erfolgreiche Authentifizierung des zugreifenden Subjekts als persistenten Identifier, die eIAM ID der Verbundidentität des Subjekts im Token. Dies im Gegensatz zu Integrationen mit Autorisierungsleistung, wo als persistenter Identifier die userExtId der Identitätsreferenz im Access Mandant verwendet wird. Dieser Unterschied ist zu beachten für den Fall, dass Applikationen untereinander Daten über das Subjekt austauschen sollen. In diesem Fall soll aufgrund der unterschiedlichen Identifier das Pattern "Authentication Only" nicht verwendet werden.

Das Integrationsmuster "Authentication Only" ist verfügbar für elektronische Identitäten der folgenden Identity Provider (IdP):

• CH-LOGIN (inklusive BYOI Bundle)
  
• FED-LOGIN

IDM ist das zentrale Management-Tool für Verwaltung der IDM-Rollen, Mandanten, Organisationen, Fachapplikationen, Geschäfts- und Fachapplikationsrollen und die Benutzerdaten und Profil. In der IDM Datenbank sind die Daten abgelegt, die bei der Authentisierung und Autorisierung der Applikationszugriffe benötigt werden.

• GKD (Gesamtkoordinator Dienst)
  
• GKA (Gesamtkoordinatoren Amt)
  
• BVA (Benutzerverwalter Applikation)
  
• BVG (Benutzerverwalter Geschäftsrolle)

Infolink:

Applikationsverantwortliche haben die Möglichkeit Meldungen (Information, Wartung oder Incident) für Ihre Applikationen einfach und mit grösstmöglicher Autonomie zu verwalten. Diese Meldungen werden dem End-Benutzer nach dem Öffnen der Fachapplikation URL angezeigt.

Infolink:

Die FED-LOGIN Access App ist die einfachste und gleichzeitig sicherste Methode für Sie, wenn Sie mit einer Smartcard der Bundesverwaltung ausgerüstet sind und Sie sich am FED-LOGIN mit einem Gerät anmelden wollen, welches die Nutzung Ihrer Smartcard nicht unterstützt (zum Beispiel Smartphones, Tablets, PC ohne Smartcardleser, Mobile VDI). Die FED-LOGIN Access App Methode ermöglicht ein Login dessen Qualität die Anforderung der meisten eIAM integrierten Anwendungen der Bundesverwaltung erfüllt.

Registrierung der FED-LOGIN Access App:

eIAM Self-Service Webapplikation für Benutzerinnen und Benutzer der FED-LOGIN und CH-LOGIN Verfahren, um ihre persönlichen Benutzerprofildaten, die Login Faktoren (Credentials) wie Passwort und Login-Zweitfaktoren zu verwalten.

eIAM PROD Stage:
eIAM ABN Stage:
eIAM REF Stage:

Die Komponente eIAM-AM bildet einen Attribute Provider und erlaubt die Administration von Identitäten, Identitätsreferenzen, Berechtigungen und anderen für das Identity- und Accessmanagement nötiger Attributen. Diese Funktion wird von einem mandantenfähigen IDM System übernommen, welches die Partitionierung und Verwaltung über Datenräume erlaubt. eIAM-AM stellt einer Verwaltungseinheit (Amt oder Generalsekretariat) einen eigenen Access Mandanten für die Administration der Benutzerberechtigungen im eIAM zur Verfügung.

eIAM PROD Stage:
eIAM ABN Stage:
eIAM REF Stage:

Das delegierte Management hat zum Ziel das Management der Berechtigungsvergabe zu dezentralisieren und dabei das Management dort hin zu leiten, wo auch das Know-how über Veränderungen vorhanden ist.

eIAM PROD Stage:
eIAM ABN Stage:
eIAM REF Stage:

Das ePortal ist eine Plattform für Online-Services der Bundesverwaltung mit direktem Zugriff für Bürgerinnen und Bürger, Unternehmen und Verwaltungen sowie interne Nutzer. Das ePortal ist bereits an eIAM angeschlossen ist.

ePortal PROD Stage:
ePortal ABN Stage:
ePortal REF Stage:

Ziel dieser Webapplikation ist, dass natürliche Personen sich gegenseitig beweisen können, dass sie ein Login mit einer abgeklärten elektronischen Identität durchgeführt haben. Die Prüfung der Identitäten erfolgt visuell und kann von allen Teilnehmenden unter gemacht werden. Infolink:

FIDO steht für Fast IDentity Online. Es handelt sich um mehrere offenen, lizenzfreien Standards und Protokolle der FIDO Alliance zur sicheren und benutzerfreundlicheren Authentifizierung im Internet. Es gibt verschiedene Implementierungen von FIDO, darunter FIDO U2F (Universal Second Factor) und FIDO2, die in modernen Webbrowsern und Plattformen weit verbreitet sind. Mithilfe der Protokolle ist eine Passwortlose Zwei-Faktor-Authentifizierung basierend auf der Public-Key-Kryptographie möglich.

Weitere Infos unter:

Fully Qualified Domain Name: Mit jedem voll qualifizierten Domain-Namen (FQDN = Fully Qualified Domain Name) kann ein beliebiges physisches oder virtuelles Objekt weltweit eindeutig adressiert werden z.B. www.bit.admin.ch.

Java Script Object Notation. JSON wird zur Übertragung und zum Speichern strukturierter Daten eingesetzt.

JSON Web Signature (JWS) ist eine Signierungsmechanismus für JSON web token (JWT).

JSON Web Token (JWT) is ein offen Standard RFC 7519 Method für die sichere Repräsentation von “Claims” zwischen zwei Parteien.

Ein Mobiltelefon, mit einer Mobile ID fähigen SIM-Karte oder eSIM eines Schweizer Telekommunikationsanbieters.

Bitte beachten Sie, dass Mobile ID mit eSIM ausser von Swisscom von den meisten Schweizer Telekommunikationsanbietern nicht unterstützt wird. Erkundigen Sie sich bei Ihrem Anbieter, ob er Mobile ID auf eSIM unterstützt.

Das Network Time Protocol (NTP) ist ein Standard zur Synchronisierung von Uhren in Computersystemen über paketbasierte Kommunikationsnetze. NTP verwendet das verbindungslose Transportprotokoll UDP. NTP wurde speziell entwickelt, um eine zuverlässige Zeitangabe über Netzwerke mit variabler Paketlaufzeit zu ermöglichen.

Organization for the Advancement of Structured Information Standards

OAuth (Open Authorization) Version 2.0 (OAuth2) ist nur ein offenes Framework, die standardisierte, sichere API Autorisierungs- Protokolle für Desktop-, Web- und Mobile Anwendungen erlauben.

OpenID Connect (OIDC) ist eine Authentifizierungsschicht, die auf dem Autorisierungsframework OAuth 2.0 basiert. Der Standard wird durch die OpenID Foundation überwacht.

Ein Identitätsanbieter der eine OpenID-Authentifizierung bereit stellt.

Policy Enforcement Point: Der Policy Enforcement Point setzt eine definierte Policy für den Zugriff auf Ressourcen durch. Der Inhalt der jeweiligen Policy kann dabei variieren. Mögliche Policies sind z.B. es dürfen nur Benutzer, die sich erfolgreich authentisiert haben, auf eine Ressource zugreifen. Oder es dürfen nur Benutzer mit einer bestimmten Rolle auf eine Ressource z.B. Applikation zugreifen. Es darf nur zu bestimmten Tageszeiten auf eine Ressource zugegriffen werden, es darf nur mit einer bestimmten Authentisierungsstärke (QoA) auf eine Ressource zugegriffen werden etc.

Policy Enforcement Point (optional) der ausserhalb der Netze der Bundesverwaltung gehosteten Web Applikation.

• Kann der extern gehosteten Applikation vorgeschaltet sein und so aus der Sicht des eIAM-Web PEP den SAML Service Provider darstellen.
  
• Kann je nach Ausprägung WAF Funktionen und Access Management zur Laufzeit wahrnehmen.
  
• Komponente in der Verantwortung des Leistungsbezügers des Service eIAM, nicht in der Verantwortung von eIAM.

Wenn Benutzer z. B. Inhaber einer elektronischen Identität der SG-PKI beim Autoprovisioning vorgängig eingelesen werden, wird in den Benutzer Stammdaten auch das Quellsystem erfasst

Realm steht im Englischen für Reich, Bereich, Domäne. Bei Verzeichnisdiensten wie Active Directory, die z. B. über LDAP angesprochen werden, bezeichnet Realm die Gesamtheit aller Einträge eines Verzeichnisses bzw. benennt das Verzeichnis an sich. Typischerweise handelt es sich um eine Sammlung aller menschlichen und technischen Benutzer der IT-Systeme eines Unternehmens. Verzeichnisdienste werden beispielsweise für Single Sign-on(SSO)-Architekturen verwendet. Der Realm sagt der Anwendung, gegen welche Instanz eines Verzeichnisdiensts die Authentifizierung erfolgen soll.

Relying Party (Begriff Microsoft) auch Service Provider (bei OASIS). Die Relying Party vertritt die Interessen der Ressource. Sie nutzt IAM-Geschäftsservices und verarbeitet Informationen von IAM-Dienstanbietern für den Schutz seiner Ressourcen. Sie braucht zur Beurteilung der Berechtigung eines Ressourcenzugriffs nähere Informationen zu einem Subjekt.

Security Assertion Markup Language Version 2.0.• Die Security Assertion Markup Language (kurz SAML) ist ein XML-Framework zum Austausch von Authentifizierungs- und Autorisierungsinformationen. Sie stellt Funktionen bereit, um sicherheitsbezogene Informationen zu beschreiben und zu übertragen

Single-Logout: Verfahren um in einer SSO Domäne alle verwendeten Relying Parties über das Ende der Benutzersession zu informieren. So dass diese ihrerseits die Sessions des Endbenutzers sauber schliessen.

Der Service Provider bietet den berechtigten Benutzern Dienste und geschützte Daten an. Dies nachdem er zur Laufzeit anhand der vom IdP gemachten Aussagen geprüft hat, ob der jeweilige Zugriff des Benutzers auf die gewünschte Ressource erlaubt ist. Im eIAM wird der SP durch den eIAM-Web PEP zusammen mit der Applikation gebildet.

Der Benutzer ruft als erstes die Zielapplikation (=Serivce Provider) auf. Die Zielapplikation leitet dann den Browser des Benutzers zwecks Authentisierung des Benutzers an eIAM.

Eine Authentifizierungsmethode, die es Benutzern ermöglicht, sich einmal anzumelden und dann auf mehrere angeschlossene Systeme zuzugreifen, ohne sich erneut anmelden zu müssen.

Eine definierte Menge von Relying Parties, welche alle dem gleichen Identity Provider vertrauen und in einer Domäne zusammengefasst werden. Ein Endbenutzer muss sich nur einmalig an der SSO Domäne anmelden und kann mit dieser Authentifizierung alle Ressourcen in der SSO Domäne nutzen.

Im eIAM ein Benutzer. Dies kann ein Mitarbeiter der Bundesverwaltung oder ein Bürger sein, der eine Fachanwendung oder eine eGOV Anwendung der Bundesverwaltung nutzen will. Grundsätzlich kann ein Subjekt aber auch eine Gruppe darstellen.

Transport Layer Security, auch bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), ist ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet.

Ein Uniform Resource Locator identifiziert und verortet eine Ressource wie z. B. eine Webseite über die zu verwendende Zugriffsmethode und den Ort der Ressource in Computernetzwerken. Der aktuelle Stand ist als RFC 1738 publiziert.

Ein Uniform Resource Identifier (Abk. URI, englisch für einheitlicher Bezeichner für Ressourcen) ist ein Identifikator und besteht aus einer Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen Ressource dient. URIs werden zur Bezeichnung von Ressourcen (wie Webseiten, sonstigen Dateien, Aufruf von Webservices, aber auch z. B. E-Mail Empfängern) im Internet und dort vor allem im WWW eingesetzt. Der aktuelle Stand ist als RFC 3986 publiziert.

Web Browser des Benutzers

Der Term "Verifiable Credential", welcher häufig mit "Credential" abgekürzt wird, bezeichnet einen digitalen Nachweis, welcher für sich selbst sprechend ist (ein von einem Aussteller signierter Datensatz). Die Identität kann also duch vorweisen dieses "Verifiable Credentials" bewiesen werden (ohne Dritten). Credentials im Sinne von Verifiable Credentials können auch andere Aussagen enthalten. So enthält z.B. eine Wohnsitzbestätigung nicht die Aussage, um mich zu identifizieren, aber die Aussage, um zu wissen, wo denn die vermerkte Person wohnt.

Authentifizierungsdienst der Schweizer Behörden

Das Vorhaben AGOV der Digitalen Verwaltung Schweiz (DVS) macht die Login-Funktionalitäten des seit vielen Jahren bestehenden CH-LOGIN der Bundesverwaltung allen Verwaltungsebenen der Schweiz (Gemeinden, Kantone, Bund) zugänglich und bildet zusammen mit kantonalen Identitäts-Providern und der SWITCH edu-ID einen Identitätsverbund. Den direkten Einsatz der zukünftigen staatlichen Schweizer E-ID als autarkes Credential wird im Login-Verfahren von AGOV unterstützt werden. AGOV Link:

Das Modul AGOV idp speichert die nativen AGOV-Identitäten mit ihren subjektidentifizierenden Daten und führt die eigentlichen Authentifizierungen (Logins) durch. Phänotypisch manifestiert sich dies in der Login-Maske, zu finden unter .

Das Modul AGOV trustbroker fungiert als Identity Provider Interface und ermöglicht die Verbindung zwischen AGOV idp und den Zielapplikationen, die Login-Vorgänge bei AGOV anfordern, auch bekannt als Relying Parties. Dieser Verbindungsvorgang wird als Föderation bezeichnet. Als Föderationsprotokolle werden OIDC und SAML2.0 verwendet. Der AGOV trustbroker basiert auf dem "trustbroker.swiss", der als Open Source Software veröffentlicht ist (Link GitHub: ).

Das Modul AGOV me ist eine Web-Applikation, konkret das Self-Service-Verwaltungsportal für Endbenutzer. Dort können Endbenutzer ihre AGOV-Daten einsehen, ändern und Login Faktoren hinzufügen oder entfernen. Phänotypisch manifestiert sich dies in der Web-Applikation .

Das Modul AGOV connect ist eine Web-Applikation, genannt das Portal für Relying Parties (RPs), wie zum Beispiel Kantone. Hier können Relying Parties und deren Lieferanten eigenständig Applikationsanschlüsse sowohl für Test- als auch für Produktionszwecke erstellen. Die Relying Parties erhalten einen oder mehrere Datenräume in AGOV connect und verwalten diese eigenständig. Die Beantragung erfolgt bei der DVS und es steht ein Supportangebot zur Verfügung. Phänotypisch manifestiert sich dies in der Web-Applikation

AGOV-Endbenutzende können online in AGOV auf drei Arten ihren Ausweis prüfen lassen: durch den BmID-Vor-Ort-Service der Schweizer Post, durch Videoidentifikation von Intrum oder durch den Besuch eines kantonalen AGOV-Schalters, sofern der Kanton solche anbietet. Das Modul AGOV counter ist die Web-Applikation für das entsprechende Schalterpersonal, das Vor-Ort-Face-to-Face-Identitätsprüfungen mit AGOV-Endbenutzenden, sprich Bürgerinnen und Bürgern, am Schalter durchführen. Phänotypisch manifestiert sich dies in der Web-Applikation

Das Modul AGOV help (in der AGOV-Studie noch als AGOV support ist eine Web-Applikation, die das Portal für AGOV-Endbenutzer darstellt. Es enthält Anleitungen und bietet die Möglichkeit, Support-Tickets zu eröffnen. Phänotypisch manifestiert sich dies in der Web-Applikation .

Das Modul AGOV verifier wird aktiviert, wenn AGOV-Benutzende die Schweizer E-ID als Login Faktor verwenden (weder die AGOV-Erstregistrierung noch die AGOV access App sind bei dieser AGOV-Verwendung notwendig). Die Endbenutzenden erhalten eine Push-Benachrichtigung und öffnen die Wallet-App auf ihrem Smartphone, die ihre E-ID enthält. Dort genehmigen sie die Übermittlung ausgewählter subjektidentifizierender Attribute an AGOV.

Die AGOV access App ist eine native Mobile App für Smartphones und Tablets mit den Betriebssystemen iOS und Android. Die App ist kostenlos in den entsprechenden App-Stores erhältlich, Infolink: . Neben der Schweizer E-ID auf der einen Seite und hardwarebasierten FIDO-Sicherheitsschlüsseln auf der anderen Seite ist die AGOV access App der einzige für AGOV zugelassene Login Faktor.

Die Leistung von AGOV identity proof & pay ist, dass in AGOV amtliche Lichtbildausweise mit unterschiedlichen Methoden vorgewiesen, registriert und kontrolliert (inkl. Gesichtsabgleich) werden können und ggf. online durch die Endbenutzenden bezahlbar sind. Es handelt sich hierbei nicht um ein einziges Modul, AGOV identity proof & pay ist ein Zusammenspiel von diversen Teilsystemen.

Das Modul AGOV view ermöglicht den L1-Supportenden den Einblick in AGOV-Konten. Die Anforderungen an die Gouvernanz diesbezüglich sind sehr hoch, deshalb ist die Umsetzung noch nicht beschlossen.

Das Modul AGOV crypt ermöglicht den L2-Supportenden das Hochladen von Unterlagen mit erhöhtem Schutzbedarf mit der Folge der Speicherung als Chiffrate, welche nur mit dem Schlüssel aus dem BK-Tresor geöffnet werden können.

Authentisierungsqualitäten von AGOV:

• AGOVaq100: Selbstdeklariertes AGOV-Login
  
• AGOVaq200: Adressgeprüftes AGOV-Login
  
• AGOVaq300: Identitätsgeprüftes AGOV-Login ohne AHV-Nummer
  
• AGOVaq400: Identitätsgeprüftes AGOV-Login mit AHV-Nummer
  
• AGOVaq500: AGOV Login mit E-ID