Startseite Navigation Inhalt Kontakt Sitemap Suche

Anschluss von Applikationen an eIAM

Merkblatt für Beschaffungen
V1.7 2024-10-09 ▪ Auch verpflichtend für Eigenentwicklungen und andere Formen der Einführung neuer Software

Das vorliegende Merkblatt muss bei Beschaffungen betroffener IKT-Lösungen integraler Bestandteil der Anforderungen sein; es kann mit der URL referenziert werden.

Das vorliegende Merkblatt ist für die AGOV-Nutzung durch die Kantone und ihre Gemeinden nicht anwendbar. Applikationen des Bundes werden nicht direkt an AGOV angeschlossen, sondern gemäss dem hier vorliegenden Merkblatt an eIAM; im eIAM-Ökosystem steht AGOV automatisch zur Verfügung.


Für die meisten Applikationen, einschliesslich nativer Mobile-Apps, gilt eine eIAM-Bezugspflicht gemäss . Evaluieren Sie die Bezugspflicht für Ihren Fall in der Checkliste Ⅴ’’’

alles ausklappen ▼

Ⅰ Einleitung

Das vorliegende Merkblatt behandelt den Anschluss von Applikationen an eIAM.

EINLEITUNG
×

Hintergrund

Webapplikationen und native Mobile Apps der Bundesverwaltung, unabhängig von Betriebsort, Betriebsform und Schutzbedarf, nachfolgend adressiert als „Applikationen“, müssen die Authentifizierungsleistungen beim entsprechenden Standarddienst der Bundesverwaltung beziehen (vgl. ). Handelt es sich um Applikationen des Justizumfelds und Affiliierter, ist der Service „SSO-Portal“ des EJPD zu nutzen, in den anderen Fällen der Service eIAM (direkter und indirekter eIAM-Anschluss ist möglich; indirekte Anschlussvarianten: über ePortal oder über IAM-WBF).

Bezugspflicht und Bedeutung bei Beschaffungen

Die Bezugspflicht betreffend die Authentifizierungsleistungen und der daraus folgende Ausschluss anderer (proprietärer) IAM-Versorgungen, z. B. eingebaut in den Applikationen oder ihren Betriebsumgebungen (SaaS und andere Cloudbetriebsformen), bedeutet bei Beschaffungen, dass die – wenn möglich einfache – Anschlussmöglichkeit an den Standarddienst für die Beschaffung ein MUSSKRITERIUM ist. Das vorliegende Merkblatt muss als Beilage bei Beschaffungen als Quelle der Definition der MUSSKRITERIEN und des Weiteren der KANNKRITERIEN (Aspekte der einfachen Anschlussmöglichkeit) verwendet werden.

Fokus der Bezugspflicht, Abgrenzung

Die Bezugspflicht betrifft die digitalen Identitäten und ihre Credential und die daraus resultierenden Authentifizierungsleistungen. In der Folge dürfen die Applikationen oder ihre Betriebsumgebungen (z. B. SaaS und andere Cloudbetriebsformen) eigene Benutzerverwaltungen mit Autorisierungsdaten (Rechte wie Rollen und Attribute) führen, solange die Authentifizierungsleistungen ausschliesslich von eIAM bezogen werden.

Ⅱ KRITERIEN

Es müssen die prinzipielle Anschlussmöglichkeit und die Einfachheit deren Ausprägung unterschieden werden.

Ⅱ’ MUSSKRITERIEN
×

MUSSKRITERIUM 1: Prinzipielle Anschlussmöglichkeit

Die prinzipielle Anschlussmöglichkeit ist gegeben, wenn die Applikationen mit eIAM föderieren können, und dies über eines der folgenden Protokolle:
  1. OIDC mit Authorization Code Flow & PKCE (Proof Key of Code Exchange)
  2. SAML2.0 mit Browser POST Binding
  3. SAML2.0 mit Browser Redirect Binding
  4. WS-Federation

MUSSKRITERIUM 2: Service Provider First inkl. Data / Transport

eIAM arbeitet wie im Video auf ab Minute 7 gezeigt mit dem Pattern „Service Provider First“, was bedeutet, dass der Endbenutzer zuerst die Zielapplikation aufruft, diese den Benutzer als noch nicht authentisch erkennt und in der Folge den Browser zu einem Redirect formal und inhaltlich gemäss OIDC oder SAML2.0 oder WS-Federation nach eIAM veranlasst.

Dazugehörend sind die folgenden Aussagen zu Data / Transport:

  • Die Applikation MUSS* in der Lage sein, Single Logout über das Föderationsprotokoll zu initiieren
  • Die Applikation MUSS in der Lage sein, die Authentifizierungsanfrage zu signieren (Optional. Nur falls keine fixe Assertion Consumer Service URL)
  • Die Applikation MUSS* Bearer Token akzeptieren
  • Föderationsnachrichten werden von eIAM nur über auf dem Transport Layer gesicherte Verbindungen (TLS) empfangen und übermittelt.
*Wenn nicht erfüllbar, kann ein eIAM-Anschluss trotzdem möglich sein.

Ⅱ’’ KANNKRITERIEN (Aspekte der einfachen Anschlussmöglichkeit)
×

Da der Berührungspunkt zu eIAM nicht direkt auf der Applikation liegen muss, sondern auch eine Fassade des Betreibers sein kann, wird nachstehend von Berührungspunkt zwischen eIAM und Ziel anstatt zwischen eIAM und Applikation gesprochen.

KANNKRITERIUM 1: Verwendung der Tokens von OIDC oder SAML2.0 oder WS-Federation gemäss eIAM-Standard

eIAM schreibt in den Tokens bestimmte Daten in bestimmte Felder. Der Anschluss an eIAM wird vereinfacht, wenn das Ziel damit umgehen kann, vgl. Dokumentation unter .

Bei Nichterfüllung des KANNKRITERIUMS 1: Benötigt das Ziel andere Felder, bietet eIAM eine gewisse Flexibilität (Umschreibung / Mapping) ggf. unter Kostenfolge. Zielapplikationsspezifische Änderungen der eIAM-Tokens (OIDC, SAML2.0, WS-Federation) muss über den Prozess P035 () beantragt werden.

KANNKRITERIUM 2: OIDC oder SAML2.0 oder WS-Federation als einziger Berührungspunkt (keine Schnittstellen)

Der Anschluss ist vereinfacht, wenn eines der vorerwähnten Protokolle der einzige Berührungspunkt zwischen eIAM und Ziel ist, in anderen Worten, wenn keine Schnittstellen zwischen eIAM und dem Ziel dahingehend bestehen müssen, dass a) Benutzerdaten aus eIAM ausgelesen werden müssten, b) nach eIAM geschrieben werden müssten oder dass c) eIAM auf einem anderen Kanal als dem aus OIDC oder SAML2.0 oder WS-Federation resultierenden Token zum Ziel schicken (provisionieren) müsste.
Das bedeutet für das Ziel, dass die resultierenden Tokens von OIDC oder SAML2.0 oder WS-Federation die einzige externe Quelle mit Benutzerinformationen sind und dass, wenn das Ziel die Benutzerdaten persistieren soll, dies just-in-time aus den Tokens geschehen muss.

Bei Nichterfüllung des KANNKRITERIUMS 2: Benötigt das Ziel Schnittstellen im Sinne von a), b) und/oder c), ist das nächste Kapitel zu konsultieren.


Ⅱ’’’ NICHTERFÜLLUNG VON KRITERIEN (Auflösung der resultierenden eIAM-Inkompatibilität)
×

Werden IKT-Lösungen beschafft, dies gilt auch für Cloud-Lösungen inkl. SaaS, welche nicht an eIAM innerhalb des eIAM-Standards angeschlossen werden können, ist der Applikationseigner verpflichtet, eine Authentication Bridge im Sinne eines Adapters entwickeln zu lassen und zu betreiben. Vgl. .

Ⅲ SCHNITTSTELLEN

Die Schnittstellen von eIAM werden nicht dem Ziel angepasst, sondern umgekehrt.

SCHNITTSTELLEN
×

Bei der Notwendigkeit des Einsatzes der nachstehend aufgeführten Schnittstellen soll so früh wie möglich das Gespräch mit BK DTI / BIT gesucht werden.

Sind Schnittstellen wie obenstehend und nachfolgend beschrieben notwendig, bleibt der Anschluss an eIAM möglich, es muss aber den Schnittstellen-Vorgaben von eIAM gefolgt werden, die Schnittstellen von eIAM werden nicht dem Ziel angepasst, sondern umgekehrt.

Führt dies zu einer Inkompatibilität zwischen Ziel und eIAM und das Ziel kann nicht angepasst werden (die Bereitschaft hierfür ist bei SaaS-Anbietern manchmal nicht gegeben), ist der Anschluss an eIAM gefährdet. Solche Applikationen sollten nicht beschafft werden. Ist dies trotzdem notwendig, muss der Kunde auf seine Kosten im BIT oder anderswo einen Adapter im Sinne einer vermittelnden Fachapplikation (vgl. ) entwickeln und betreiben lassen. Eine solche Inkompatibilität führt nicht automatisch zu einer Ausnahmebewilligung für den Betrieb ohne eIAM.

Es ist darauf zu achten, dass alleinige Angaben eines Herstellers wie "SAML2.0-fähig" oder "OIDC-fähig" oder "WS-Federation-fähig" nicht genügen, hierzu ein Beispiel: Die SaaS X. ist SAML2.0-fähig, benötigt aber eine Provisionierung der Benutzer auf ihre proprietäre API; es ist ausgeschlossen, dass eIAM als Service eines Standarddienstes diese proprietäre Provisionierung leistet (Gebot der Wiederverwendbarkeit). Für die SaaS X. wurde in der Folge ein Adapter im Sinne einer vermittelnden Fachapplikation (vgl. ) entwickelt.

Schnittstelle eIAM-RDM

eIAM-RDM ermöglicht das Einladen von Benutzern in eIAM mittels einer REST (Representational State Transfer) API. RDM steht für Remote Delegated Management. Beim Delegierten Management geht es prinzipiell darum, dass nicht der Berechtigungsverantwortliche eines Amtes BVA Berechtigungen vergibt, sondern jemand anderes (vgl. dazu Leistung 6 und eIAM-Video bei Minute 11). Bei der Verwendung von RDM löst nicht ein Mensch die Einladung in eIAM aus, sondern eine Maschine. In beiden Fällen sendet eIAM der eingeladenen Person eine E-Mail mit einem Einladungstext und Onboardingcode. Die eingeladene Person löst den Onboardingcode unter Verwendung einer adäquaten digitalen Identität ihrer Wahl einmalig ein, somit ist diese procfactinter Identität über eIAM mit der Zielapplikation verbunden.
Verwendungserwägung: Die Erwägung, ob eIAMs delegiertes Management im Allgemeinen und eventuell im Speziellen über RDM genutzt werden soll, stellt auf der Modellierung der Onboardingprozesse, also der Frage "wie kommen Benutzer erstmalig in die Zielapplikation", ab (vgl. dazu den Abschnitt ONBOARDINGVERFAHREN weiter unten).

Schnittstelle eIAM-AMW

eIAM-AMW bietet eine SOAP (Simple Object Access Protocol) API, welche das Lesen und Mutieren von Benutzerdaten und Organisationsstrukturen in eIAM ermöglicht. In andern Worten, eIAM-AMW ist die Schnittstelle zum eIAM-Accessmandanten.
Verwendungserwägung: Die Verwendung dieser Schnittstelle ist die Antithese zum oben erwähnten KANNKRITERIUM 2 und es empfiehlt sich die Reflexion, wie das KANNKRITERIUM 2 folgend dem Gebot der Einfachheit erfüllt werden könnte.

Schnittstelle eIAM-LDS

eIAM-LDS ermöglicht das Auslesen von Benutzerdaten über das Lightweight Directory Access Protokoll LDAP. Die LDAP-Schnittstelle steht nur Applikationen zur Verfügung, welche in den Netzen der BVerw betrieben werden. Hierzu stellt eIAM die Angaben zu den Benutzern einer Applikation in einem entsprechenden Verzeichnis dediziert zur Verfügung.
Verwendungserwägung: Die Verwendung dieser Schnittstelle ist die Antithese zum oben erwähnten KANNKRITERIUM 2 und es empfiehlt sich die Reflexion, wie das KANNKRITERIUM 2 folgend dem Gebot der Einfachheit erfüllt werden könnte.

Ⅳ WEITERE ZU BERÜCKSICHTIGENDE ASPEKTE

WEITERE ZU BERÜCKSICHTIGENDE ASPEKTE
×

OHNE ODER MIT ACCESSMANAGEMENT

Ohne Accessmanagement (Authentication Only): Wenn die Zielapplikation ausschliesslich die Identität der sich einloggenden Person (zwecks Wiedererkennung) von eIAM erhalten muss, in andern Worten, in eIAM werden keine autorisierenden Daten (Rollen, Rechte etc.) gepflegt und auch keine Onboardingverfahren durchgeführt, weil dieses Accessmanagement vollständig in der Zielapplikation selber gemacht wird, ist der Einsatz eines eIAM-Accessmandanten somit nicht notwendig, sondern ein Direktanschluss der Applikation an den Bundestrustbroker BTB als leichtgewichtiges Anschlussverfahren ist angezeigt.

Mit Accessmanagement: Sollen autorisierende Daten (Rechte, Rollen etc.) ganz oder teilweise in eIAM gepflegt werden (um im Loginvorgang der Zielapplikation übermittelt zu werden) und/oder eIAM muss für die Zielapplikation Onboardingverfahren durchführen (Zugriffsanträge von Benutzenden entgegennehmen oder umgekehrt, Benutzer per E-Mail oder Brief einladen inkl. delegiertes Management), ist die Verwendung eines eIAM-Accessmandanten zwingend. Für die somit im eIAM-Accessmandanten abzubildenden Rollen, Rechte etc. gilt, dass erstens die Anzahl überschaubar sein muss (nicht hunderte), zweitens Veränderungen (hinzufügen, entfernen, umbenennen von Rollen, Rechten etc.) nicht häufig ist (jeweils Auftrag an das BIT notwendig) und dass keine dynamische Einlesung von Rollen, Rechten etc. von externen Quellen notwendig ist.

ONBOARDINGVERFAHREN

Es wird empfohlen, dass in den Ausschreibungsunterlagen die möglichen und darunter die präferierten Onboardingverfahren erwähnt werden. Der Begriff Onboarding beschreibt den Prozess, der dazu führt, dass ein User mit seiner digitalen Identität eine Zielapplikation benutzen kann. Die Onboardingverfahren sind unter → Leistung 5 beschrieben. Die Anbietenden müssen auf diese Onboardingverfahren eingehen und beschreiben, wie diese mit ihrer Lösung funktionieren können. Ausschreibende wie Anbietende können dafür BIT / BK DTI konsultieren.

ERHÖHTER SCHUTZBEDARF

eIAM setzt die Zonenpolicies der Netzwerkzonen SZ+ und BV-Netz durch und erlaubt Zugriffe in die genannten Zonen nur nach einer vorgängigen Authentifizierung mit einer QoA von mindestens 50.

EIAM-VERSORGUNG VON CLOUD-LÖSUNGEN

Die Versorgung von Applikationen in AWS und Azure und anderen Clouds wird erfolgreich praktiziert. Insbesondere Azure definiert viele Vorbedingungen. Deshalb wird empfohlen, bezüglich der Beschaffung von Cloud-Lösungen BIT / BK DTI so früh wie möglich mit einzubeziehen. SaaS und andere Cloud-Patterns unterstehen der Bezugspflicht .

Ⅴ CHECKLISTEN

Ⅴ’ CHECKLISTE KRITERIEN & ASPEKTE
×

Download Checklisten V' (WORD DOCX)

 Ⅴ’ CHECKLISTE KRITERIEN & ASPEKTE

MUSSKRITERIUM 1: Prinzipielle Anschlussmöglichkeit
☐ erfüllt, nämlich via Protokoll ____________

MUSSKRITERIUM 2: Service Provider First inkl. Data / Transport
☐ erfüllt inkl. Data / Transport

KANNKRITERIUM 1: Verwendung der Tokens von OIDC oder SAML2.0 oder WS-Federation gemäss eIAM-Standard
☐ ja, erfüllt
☐ nein, das Ziel benötigt andere Felder / Daten
      (genaue Beschreibung durch den Anbieter notwendig, Prüfung der Angebote durch BK DTI und BIT empfohlen)

KANNKRITERIUM 2: OIDC oder SAML2.0 oder WS-Federation als einziger Berührungspunkt (keine Schnittstellen)
☐ ja, erfüllt
☐ nein, Ziel benötigt Schnittstellen zu eIAM
      (genaue Beschreibung durch den Anbieter notwendig, Prüfung der Angebote durch BK DTI und BIT empfohlen)

ACCESSMANAGEMENT
☐ Ohne eIAM-Accessmanagement (Authentication Only),
      d. h. keine Rechte, Rollen etc. in eIAM, alles in der Zielapplikation
☐ Mit eIAM-Accessmanagement, weil
☐ ☐ alle oder ☐ gewisse Rechte und Rollen (Anzahl: ______ ) in eIAM verwaltet und/oder
     ☐ das Onboardingverfahren-/ ☐ das delegierte Management von eIAM verwendet wird.
☐ Anbietende sind darauf eingegangen

ONBOARDINGVERFAHREN
☐ obsolet, da Authentication Only
☐ Präferenz / Szenario der Beschaffenden ist definiert
☐ Anbietende sind darauf eingegangen

BETRIEBSFORM
Im BIT (Atlantica, VM ...), extern, SaaS, Cloudlösung etc.)

☐ __________________________________________


Ⅴ’’ CHECKLISTE LOGINVERFAHREN & -QUALITÄT
×

Download Checklisten V'' (WORD DOCX)

 Ⅴ’’ CHECKLISTE LOGINVERFAHREN & -QUALITÄT


In den Abschnitten b) und c) soll nur jeweils einmal «ja» gewählt werden.

Innerhalb der Abschnitte b) und c) sind die Anforderungen von tief nach hoch angeordnet. Die hohen Anforderungen können aus Geschäftsanforderungen hervorgehen, es sollte aber keine unnötige Nivellierung noch oben gemacht werden, sondern «nur» die IKT-Vorgaben des Bundes erfüllt werden, insbesondere Si001

a) Loginverfahren:

☐ja / ☐nein
Inhabende eines FED-LOGIN (Mitarbeitende der BVerw und damit ausgerüstete Affiliierte wie gewisse kantonale Mitarbeiter) sollen via FED-LOGIN einloggen können.

☐ja / ☐nein
Personen ohne FED-LOGIN sollen (auch) einloggen können (Partner, Private etc. via AGOV, CH-LOGIN und angeschlossene Drittidentitätsprovider).


b) Authentifizierungsqualität, Teil Identitätsprüfung (auch Identitätsabklärung genannt):

☐ja / ☐nein
Es reicht, wenn die Person ihre Daten im Loginverfahren (bei der Eröffnung des Loginkontos) selbst deklariert, keine weitere Überprüfung.
Begründung: _____________________________________________________

☐ja / ☐nein
Es reicht, wenn die Person ihre Daten im Loginverfahren (bei der Eröffnung des Loginkontos) selbst deklariert, aber die Angaben müssen zu einem Registerdatensatz passen (z. B. Post-Personen-Adressdatenbank, HR-Datenbank).
Begründung: _____________________________________________________

☐ja / ☐nein
Die Angaben zur Login-inhabenden Person müssen verlässlich sein, und zwar auf der Grundlage eines hinterlegten und mit dem Gesicht der Person abgeglichenen amtlichen Lichtbildausweises.
Begründung: _____________________________________________________


c) Authentifizierungsqualität, Teil Härtung der Loginfaktoren:

☐ja / ☐nein
Ungehärtete Loginfaktoren wie Passwörter und SMS-mTAN dürfen eingesetzt werden. Innerhalb der Bundesverwaltung gilt auch Kerberos als ungehärtet.
Begründung: _____________________________________________________

☐ja / ☐nein
Es dürfen ausschliesslich gehärtete Loginfaktoren (z. B. FIDO-basierte Access Apps, FIDO Sicherheitsschlüssel, Smartcards) eingesetzt werden.
Begründung: _____________________________________________________


BK DTI und BIT beraten bezüglich der Betriebsformen ohne Kostenfolge.


Ⅴ’’’ CHECKLISTE IAM-VERSORGUNG BUNDESVERWALTUNG, VORGABEN, BEZUGSPFLICHT
unorthodoxesprungmarke
×

Download Checklisten V''' (WORD DOCX)

 Ⅴ’’’ CHECKLISTE IAM-VERSORGUNG BUNDESVERWALTUNG, VORGABEN, BEZUGSPFLICHT

Synopsis
×

Als IAM-Versorgung in der Bundesverwaltung werden alle Vorgänge verstanden, bei denen eine digitale Identität zur Authentifizierung der handelnden Entität eingesetzt wird (Identity), ggf. gefolgt von autorisierenden Zusatzangaben (Access).

Das Ziel der vorliegenden Checkliste ist die Diskriminierung innerhalb zwei Fragestellungen:

  1. Welches IAM-System kann/muss verwendet werden?
  2. Welche Qualität muss die Authentifizierungsleistung erreichen?

Den beiden Fragestellungen zu Grunde liegen verschiedene Informationsquellen, deren Synthese nicht einfach ist:

Für Punkt 1 spielt erstens die Bezugspflicht des entsprechenden Standarddienstes eine Rolle, wobei der Standarddienst zwei Services anbietet, und zweitens liegen dedizierte Fälle ausserhalb der Bezugspflicht.

Für Punkt 2 sind die Resultate der Schutzbedarfsanalyse massgebend, diese werden aber durch viele Zusatzüberlegungen komplementiert.

Die vorliegende Checkliste soll in vielen Fällen die beiden Fragestellungen direkt operationalisierbar beantworten.

Checkliste

Diese Checkliste ist nicht eIAM-spezifisch, sondern auf jede Konstellation in der Bundesverwaltung anwendbar. Bitte jede Frage mit "ja" oder "nein" beantworten. Die Fragen beziehen sich konkret auf eine Zielapplikation oder ein Portal mit mehreren Zielapplikationen.

Name der Applikation, des Portals: _________________________________
(nachfolgend als "Ziel" bezeichnet. Auch intermediäre IAM-Systeme (z. B. ePortals PAMS), hinter denen mehrere Applikationen liegen, können das Ziel sein.)


    A. SUBJEKTE
  1. ☐ja / ☐nein: Müssen Menschen sich im Ziel anmelden (einloggen?)

  2. ☐ja / ☐nein: Müssen Maschinen sich im Ziel anmelden (einloggen?)
    3. Wenn zweimal nein, keine IAM-Versorgung notwendig, die vorliegende Checkliste ist nicht anwendbar.
    Wenn Frage 2 = ja, bitte BK DTI kontaktieren.


    B. ZIELOBJEKT (ZIELAPPLIKATION / ZIEL)
  3. ☐ja / ☐nein: Ist das Ziel eine Webapplikation (etwas, das im Browser läuft)?
    4. Wenn ja, Bezugspflicht (Bezugspflicht gilt für die zentrale BVerw. Dezentrale kann unter Bedingungen beziehen). Gilt unabhängig von Hoster und Hostingzone, auch SaaS wie Atlassian Cloud etc. fallen unter die Bezugspflicht

  4. ☐ja / ☐nein: Ist das Ziel eine Mobile-App (auf dem Smartphone/Tablet)?
    5. Wenn ja, Bezugspflicht (Bezugspflicht gilt für die zentrale BVerw. Dezentrale kann unter Bedingungen beziehen).

  5. ☐ja / ☐nein: Ist das Ziel eine Client-Applikation auf einem Endgerät (z. B. Fat-/Rich-Client)?
    Unerwünschte Technologie, BK DTI kontaktieren

  6. ☐ja / ☐nein: Ist das Ziel eine Client-Applikation auf einem Server, z. B. fernbedient über eine Terminalemulation wie Citrix?
    Unerwünschte Technologie, BK DTI kontaktieren

  7. ☐ja / ☐nein: Ist das Ziel eine IOT-Entität (z. B. Fenster-Rollladenmotor, Türöffner, Ausweisgates (z. B. Flughafen), Arbeitsroboter/Arbeitsautomaten inkl. Softwareroboter auf BAB- oder anderen Clients etc.)?
    Betreffend IAM für IOT bitte die BK DTI kontaktieren. Bezugspflicht anwendbar, Praxisetablierung im Gange.

  8. ☐ja / ☐nein: Sind alle obenstehenden Fragen in der vorliegenden Sektion B. mit nein beantwortet?
    Wenn zutreffend, BK DTI konsultieren.


    C. ZIEL-VERANTWORTUNG (fachlich Applikationsverantworlicher AV)
  9. ☐ja / ☐nein: Gehört der Auftraggeber der Zielnutzung zur zentralen BVerw oder ist anderweitig der Digitalisierungsverordnung (DigiV) unterstellt?
    10. Wenn nein, Bezugspflicht aus Sektion A. obsolet. Freiwilliger Bezug für nicht-zentrale BVerw (äussere Kreise) unter Bedingungen möglich und oft empfohlen.


    D. SCHUTZBEDARF
    Wichtig: Der Schutzbedarf hat KEINEN Einfluss auf die Bezugspflichtsaussagen der Sektionen A. bis C. !
  10. ☐ja / ☐nein: Ist das Ergebnis der Schutzbedarfsanalyse "Grundschutz"
    11. Wenn ja, muss die Authentifizierungsleistung gemäss Si001 "mittel" erreichen, gemäss www.eiam.admin.ch/qoa mindestens QoA30. Dekomponiert bedeutet dies eine 2FA-Authentifizierung ohne Notwendigkeit der Identitätsprüfung des Subjekts.

  11. ☐ja / ☐nein: Ist das Ergebnis der Schutzbedarfsanalyse "erhöhter Schutzbedarf"
    12. Wenn ja, muss die Authentifizierungsleistung gemäss Si001 "hoch" erreichen, gemäss www.eiam.admin.ch/qoa QoA50. Dekomponiert bedeutet dies 2FA-Authentifizierung mit gehärtetem Zweitfaktor und substantieller Identitätsprüfung (Abklärung) des Subjektes.


    E. ZIEL-HOSTING
    Wichtig: Der Schutzbedarf schliesst Hostings aus, die dem Schutzbedarf nicht gerecht werden!
  12. ☐ja / ☐nein: Wird das Ziel in einer Serverzone mit erhöhtem Schutzbedarf, z. B. Serverzone plus (SZ+) der BVerw, betrieben?
    13. Allfälliger Umkehrschluss nicht anwendbar. Wenn ja, muss die Authentifizierungsleistung gemäss Si001 "hoch" erreichen, gemäss www.eiam.admin.ch/qoa mindestens QoA 50. Dekomponiert bedeutet dies 2FA-Authentifizierung mit gehärtetem Zweitfaktor und substantieller Identitätsprüfung (Abklärung) des Subjektes.

  13. ☐ja / ☐nein: Wird das Ziel in einer anderen Serverzone der BVerw betrieben?
    14. Kein Einfluss auf die Bezugspflicht-Resultate aus den Sektionen A. bis C.

  14. ☐ja / ☐nein: Wird das Ziel ausserhalb der BVerw bei einem externen Betreiber, dazu gehören auch sämtliche Cloud-Lösungen, betrieben (z. B. Abraxas, Azure, AWS, Google u.v.a.)?
    15. Kein Einfluss auf die Bezugspflicht-Resultate aus den Sektionen A. bis C.


    F. LOGIN-AUDIENZ
  15. ☐ja / ☐nein: Müssen Mitarbeitende der Bundesverwaltung (Interne, Externe, ongeboardete Affiliierte (z. B. Kanton)) einloggen können?
    16. Wenn ja: Für diese Login-Audienz muss eIAMs Loginverfahren FED-LOGIN verwendet werden (bitte beachten Sie, dass das FED-LOGIN auch ohne Smartcardausgabe genutz werden kann, vgl. "totally smartcardless" ). WICHTIG: Die Art der Login-Audienz hat KEINEN Einfluss auf die Bezugspflichtsaussagen der Sektionen A. bis C., und dies gilt auch für gemietete SaaS (z. B. Atlassian-Cloud-Lösungen, Miro-Boards, Power BI etc.)!

  16. ☐ja / ☐nein: Müssen andere Personen als bei Punkt 15 definiert einloggen können? Dies sind z. B. Bürger, nicht FED-LOGIN-ongeboardete Partner (inkl. Kantone) etc.
    17. Wenn ja: Für diese Login-Audienz muss eIAMs Loginverfahren AGOV (inklusive assoziierte Dritt-IdPs wie eduID, kantonale eIDs, im Phase-Out befindliches CH-LOGIN) verwendet werden. WICHTIG: Die Art der Login-Audienz hat KEINEN Einfluss auf die Bezugspflichtsaussagen der Sektionen A. bis C., und dies gilt auch für gemietete SaaS (z. B. Atlassian-Cloud-Lösungen, Miro-Boards etc.) !

  17. ☐ja / ☐nein: Sollen sich Inhabende der staatlichen Schweizer e-ID direkt mit dieser authentifizieren können?
    18. Die Antwort auf diese Frage hat KEINEN Einfluss auf die Bezugspflicht, e-ID-Authentifizierungen müssen über den Standarddienst IAM bezogen werden, nämlich über die integrale Standarddienst-IAM-Komponente AGOV. Eine Direktanschluss der e-ID an die Zielapplikation zwecks Authentifizierung (Login) ist nicht gestattet.

  18. ☐ja / ☐nein: Müssen Personen mit Spezial-Identitätsprovidern (sog. Sektor-IdPs gemäss ) einloggen können, wie z. B. Personen des Gesundheitssektors über den Identitätsprovider HIN?
    19. Wenn ja: Dies ist möglich, bei der BK DTI zu beantragen. WICHTIG: Auch hier gilt die eIAM-Bezugspflicht, Sektor-IdPs müssen über eIAM bezogen werden und dürfen nicht an andere Systeme (Zielsysteme, intermediäre IAM-Systeme) als eIAM angeschlossen werden. Die Art der Login-Audienz hat KEINEN Einfluss auf die Bezugspflichtsaussagen der Sektionen A. bis C., und dies gilt auch für gemietete SaaS (z. B. Atlassian-Cloud-Lösungen, Miro-Boards etc.)!


    G. ACCESSMANAGEMENT
  19. ☐ja / ☐nein: Müssen Personen per E-Mail zur Nutzung der Zielapplikation durch eIAM eingeladen werden (E-Mail mit Onboarding-Code)?
    20. Die Beantwortung dieser Frage hat keinen Einfluss auf die Bezugspflicht. Wenn ja, muss das delegierte Management von eIAM genutzt werden und die Antwort auf die Folgefrage ist zwingend «ja». Allerdings kann die Zielapplikation die Einladungs-E-Mails selber abhandeln.

  20. ☐ja / ☐nein: Müssen Personen in eIAM mit Rollen und Rechten ausgestattet werden?
    21. Die Beantwortung dieser Frage hat keinen Einfluss auf die Bezugspflicht (für Identitäten und Authentifizierung gilt die Bezugspflicht, für das Accessmanagement nicht). Die Rollen und Rechte können in eIAM und oder in der Zielapplikation gepflegt werden, also auch in Mischform. Extremausprägungen: nichts betreffend Accessmanagement in eIAM, alles in der Zielapplikation (eIAM = Authentication Only) versus nichts betreffend Accessmanagement in der Zielapplikation, alles in eIAM (eIAM = mit Access Mandant), d. h. die Applikation folgt den Anweisungen im eIAM-Authentifizierungstoken.


    H. AUSDIFFERENZIERUNG BEZUGSPFLICHT
  21. ☐ja / ☐nein: Aus den Sektionen A. bis C. resultiert Standarddienst-Bezugspflicht und das Ziel ist im Polizeiwesen/Justizbereich anzusiedeln?
    22. Wenn ja: aus dem Standarddienst "Identitäts- und Zugangsverwaltung der Bundesverwaltung ()" ist der Service SSO-Portal EJPD anstatt eIAM zu nutzen.
    Beide Services werden von der BK DTI geführt.


    I. AUSFÜHRUNGEN FÜR APPLIKATIONEN IN PORTALEN
  22. Für Applikationen in Portalen wie z. B. Easygov, ePortal, eGov UVEK etc. gilt die Bezugspflicht , wobei das Portal den Übergang zu eIAM abstrahieren kann, so dass nicht die einzelne Applikation an eIAM angeschlossen werden muss, sondern nur die Portalschicht selber. Portalproprietäre Loginverfahren oder Direktanschlüsse von Identitätsprovider ebendort sind nicht zulässig.


    J. DETAILAUSFÜHRUNGEN ZU KERBEROS
  23. Webapplikationen und native Mobile-Apps dürfen nur mit Ausnahmebewilligung direkt Kerberos konsumieren, es müsste über eIAM gegangen werden.

  24. Andere Applikationen und die Büroautomation dürfen u. U. (BK DTI konsultieren) direkt Kerberos konsumieren.

  25. Kerberos erreicht die Stufe "hoch" gemäss Si001 NICHT, ausser wenn 1. die Ressource direkt in einem User-Forest der BVerw integriert ist (Freigabe von BK DTI notwendig) und 2. nachweislich die Authentifizierung auf dem benutzten Client die Smartcardnutzung erzwungen hat (z. B. auf Mobile-VDI nicht erfüllt).


    K. DETAILAUSFÜHRUNGEN ZU AGOV
  26. Die zentrale Bundesverwaltung bezieht nur in sehr seltenen bewilligungspflichtigen Ausnahmefällen AGOV "direct only"*, sondern AGOV über "full"* eIAM. Ausnahme möglich, Antrag via .

  27. Die dezentrale Bundesverwaltung kann AGOV via eIAM beziehen (es gelten Spezialbedingungen) oder AGOV "direct only"*.

  28. Andere Schweizer Behörden (Kantone, Gemeinden, Mischbetriebe) beziehen, EMBAG-Kompatibilität vorausgesetzt, AGOV "direct only"* und nicht AGOV über "full"* eIAM.
*
Schema "full" eIAM: Identitätsprovider AGOV ➤ IAM-System eIAM ➤ Zielapplikation (oder intermediäres IAM-System)
Schema AGOV "direct only": Identitätsprovider AGOV ➤ Zielapplikation (oder intermediäres IAM-System)