eIAM Glossary
Die Abkürzung E-ID gibt es in unterschiedlichen Schreibweisen (z. B. auch e-ID, eID) und steht im vorliegenden Kontext für die Begriffe elektronische Identität und elektronischer Identitätsnachweis, manchmal auch bezeichnet als digitale Identität. eIAM bietet eigene eIDs an und vermittelt als Trustbroker intern und extern produzierte eIDs (siehe eIAM-Leistung 1). Die Abkürzung eID steht für alle Arten elektronischer Identitäten und ist nicht auf staatlich anerkannte elektronische Identitäten beschränkt. Wobei sich in der Schweiz, bei durchgehender Grossschreibung dieser Abkürzung, also E-ID, die Antizipation einer staatlich anerkannten und oder staatlich herausgegebenen elektronischen Identität etabliert hat.
Diese Begriffe (elektronische Identität, elektronischer Identitätsnachweis, digitale Identität) umfassen die Gesamtheit aller Regelungen, Prozesse, Daten und Authentifikations- und Identitätsnachweismittel (Credentials), welche die eID einer Entität zuordnen und dieser Entität ermöglichen, ihre Identität mit einer bestimmten Verlässlichkeit elektronisch nachzuweisen. Solche Entitäten sind natürliche Personen, juristische Personen und Maschinen.
In der physischen Welt weisen natürliche Personen ihre Identität meistens mittels amtlicher Lichtbildausweise nach. Der Lichtbildausweis dient als Identitätsnachweis, die Sicherheitsmerkmale des Lichtbildausweises sowie die enthaltenen Daten, z. B. Gültigkeitsdauer, Geburtsdatum und insbesondere das Foto, fungieren als Authentifikations- und Identitätsnachweismittel. Pendants für die Ausübung eines elektronischen Identitätsnachweises sind Authentifikations- und Identitätsnachweismittel (Credentials) wie kryptografische Artefakte auf Datenträgern (z. B. Chipkarten), Passwörter, Einmalcodes, biometrische Merkmale, aber auch die Ausweise aus der physischen Welt, wenn diese maschinell ausgewertet werden können.
Beim Einsatz von Authentifikations- und Identitätsnachweismittel zwecks Identitätsnachweis physisch oder elektronisch stellt sich die Frage nach der Verlässlichkeit der Authentifizierungsleistung (Identitätsfeststellung) in dieser Transaktion. Relevant ist, ob die Authentifikations- und Identitätsnachweismittel echt sind, ob die wiedergegebenen Daten korrekt sind, ob die Authentifikations- und Identitätsnachweismittel der in der vorliegenden Transaktion anwesenden Entität gehört, ob und in welcher Verlässlichkeit später nachvollzogen werden kann, wie die Authentifikations- und Identitätsnachweise erfolgten und was das Resultat war sowie, grundlegend, ob die Stelle, welche den "Ausweis" ausgegeben hat, vertrauenswürdig ist.
Die staatliche Anerkennung einer E-ID stellt diese Aspekte sicher. Mit der staatlichen Anerkennung einer E-ID können die Ziele erreicht werden, dass diese E-ID eine hohe Qualität und davon abgeleitet eine hohe Verlässlichkeit aufweist sowie breit einsetzbar ist. In anderen Worten geht es darum, dass insbesondere natürliche Personen im digitalen (virtuellen) Raum mit adäquater Verlässlichkeit bezüglich ihrer Identität agieren können, wie dies bereits in der physischen Welt möglich ist. Die Grundlage für die Erreichung dieser Ziele ist, dass der Staat alle wesentlichen Aspekte von staatlich anerkannten E-IDs im Sinne dieser Ziele regelt und überwacht.
Dans le présent contexte, l'abréviation E-ID, à la graphie variable (par ex. e-ID ou eID), est utilisée pour désigner les termes identité électronique et preuve électronique d'identité. Elle est parfois aussi appelée identité numérique. eIAM propose ses propres E-ID et transmet en tant que courtier digne de confiance des E-ID produites tant en interne quen externe (voir prestations IAM 1). L'abréviation E-ID désigne tous les types d'identités électroniques et ne se limite pas aux identités électroniques reconnues par les pouvoirs publics.
Les termes mentionnés ci-dessus (identité électronique, preuve électronique d'identité, identité numérique) désignent l'ensemble des artefacts (réglementations, processus, données, moyens d'authentification et de vérification d'identité (credentials)) qui attribuent avec une fiabilité déterminée une E-ID à une unité et permettent à celle-ci de prouver son identité par voie électronique avec un degré de fiabilité spécifié. Par unités, on entend des personnes physiques, des personnes morales ou des machines.
Dans le monde réel, les personnes physiques prouvent généralement leur identité au moyen d'un document d'identité officiel muni d'une photo. Alors que le document en lui-même sert de preuve d'identité, ses éléments de sécurité et les données qu'il contient, par exemple la durée de validité, la date de naissance, et, en particulier, la photo, jouent le rôle d'attestations d'autorisation. Dans le domaine de la preuve électronique d'identité, ces éléments trouvent leur contrepartie dans les attestations d'autorisation (identifiants ou credentials) telles que les artefacts cryptographiques sur les supports de données (par ex. les cartes à puce), les mots de passe, les codes à usage unique, les caractéristiques biométriques, mais aussi les documents d'identité utilisés dans le monde réel pour autant qu'ils puissent être lus par ordinateur.
Le recours à des attestations d'autorisation en vue d'établir une identité, qu'elles soient réelles ou électroniques, soulève la question de la fiabilité de la prestation d'authentification (établissement de l'identité) employée au cours de cette opération. Il s'agit en particulier de contrôler les aspects suivants: authenticité de l'attestation d'autorisation; véracité des données fournies; appartenance du document à l'unité présente; possibilité ultérieure de traçage fiable de la méthode d'établissement de l'attestation d'autorisation et de son résultat; et, question d'importance fondamentale, la fiabilité du service qui a délivré le document en question.
La reconnaissance d'une E-ID par les pouvoirs publics permet d'aborder tous ces éléments et, partant, d'atteindre les objectifs en matière de qualité et de fiabilité de telle sorte que l'E-ID puisse être largement utilisée. En d'autres termes, les unités, et notamment les personnes physiques, doivent pouvoir opérer dans l'espace numérique (virtuel) avec une fiabilité suffisante en ce qui concerne leur identité, comme elles le font déjà dans le monde réel. Pour ce faire, les pouvoirs publics doivent réglementer et contrôler en fonction desdits objectifs tous les aspects essentiels des E-ID reconnues par les pouvoirs publics.
The abbreviation eID is written in different ways (e.g. e-ID, E-ID) and in the present context it stands for electronic identity and electronic proof of identity, sometimes also referred to as digital identity. eIAM offers its own eIDs and acts as a trust broker for internally and externally generated eIDs (see eIAM service 1). The abbreviation eID refers to all types of electronic identities and is not limited to state-recognised electronic IDs.
These terms (electronic identity, electronic proof of identity, digital identity) refer to all of the aspects (rules, processes, data, credentials) that assign an eID to an entity with a certain level of reliability and enable that entity to prove its identity electronically with a certain level of reliability. Such entities are private individuals, legal entities and machines.
In the physical world, private individuals mostly prove their identity by means of official photo IDs. These photo IDs act as proof of identity, and the security features of the photo ID and the data they contain, e.g. validity period if applicable, date of birth, and the photo in particular, act as credentials. The counterparts when providing electronic proof of ID are credentials such as cryptographic elements on data carriers (e.g. chip cards), passwords, one-time codes, biometric features, but also physical IDs, if they are machine-readable.
When using credentials for the purpose of proving identity physically or electronically, the question arises as to the level of authentication assurance (identity assurance) in this transaction, specifically: whether the credential is genuine, whether the data reproduced is correct, whether the credential belongs to the entity involved in the transaction, whether and with what level of assurance it can later be verified how the credential was issued and what the result was, and, fundamentally, whether the entity that issued the "ID" is trustworthy.
State recognition of eIDs addresses these aspects. State recognition of eIDs can achieve the goals of ensuring that these eIDs are of high quality and, consequently, have a high level of assurance and can be widely used. In other words and in particular for private individuals, it is a question of being able to operate in the digital (virtual) world with a sufficient level of assurance with regard to their identity, comparable to how this is possible in the physical world. The basis for achieving these aims is that the state regulates and monitors all essential aspects of state-recognised eIDs in line with these aims.
Eine elektronische Identität wird mittels eines oder mehrerer Credential eingesetzt. Ein Credential ist ein Artefakt, das mit einer elektronischen Identität verbunden ist und nur dem rechtmässigen Inhaber dieser elektronischen Identität zur Verfügung stehen soll, beispielsweise via Passwort.
Eine elektronische Identität für eine natürliche Person gilt als abgeklärt, wenn die Identität der natürlichen Person geprüft und zusammen mit der elektronischen Identität registriert wird (Abklärungsprozess). Dieser Abklärungsprozess stellt auf amtlichen Ausweispapieren ab, die im Moment der Credentialübergabe geprüft und erfasst werden. Auf diese Weise wird sichergestellt, dass die Credentialübergabe an die richtige Person erfolgt und dass bei Bedarf auf diese Person später wieder zurückgegriffen werden kann; zentrales Element dabei sind die Nummern der amtlichen Ausweise.
Die für abgeklärte elektronische Identitäten verwendeten Credentials sind weitgehend abhör- und fälschungssicher. Passwörter, mTAN (mobile Transaction Number, beispielsweise mittels SMS) und unpersönliche Authenticator Apps sind im eIAM-Kontext für abgeklärte elektronische Identitäten nicht genügend.
Ob für den Zugriff auf eine Ressource (z.B. eine Applikation) eine abgeklärte elektronische Identität notwendig ist, wird durch die Corporate Governance Bund und Geschäftsvorgaben definiert.
L'utilisation d'une identité électronique repose sur une ou plusieurs Credential. Une attestation d'autorisation est un élément lié à l'identité électronique dont seul le titulaire légitime de l'identité électronique en question devrait disposer (un mot de passe par exemple).
L'identité électronique d'une personne physique est considérée comme vérifiée lorsque l'identité de cette personne a été contrôlée et enregistrée en relation avec son identité électronique (processus de vérification). Ce processus de vérification se fonde sur des pièces d'identité officielles qui sont vérifiées au moment de la remise de lidentifiant (credential) et enregistrées. Ce processus permet dès lors de garantir que lidentifiant (credential) est remis à la bonne personne et qu'il sera possible de la retrouver ultérieurement si besoin est, lélément-clé en l'occurrence étant les numéros des pièces d'identité officielles.
Les identifiants (credentials) utilisés pour les identités électroniques vérifiées affichent une bonne résistance à l'interception et à la falsification. Dans le contexte eIAM, les mots de passe, les codes mTAN et les applications d'authentification non personnelles ne suffisent pas pour les identités électroniques vérifiées.
Ce sont les principes de gouvernance et les spécifications opérationnelles qui déterminent si une identité électronique vérifiée est nécessaire pour accéder à une ressource donnée.
An electronic ID is applied by using one or more proofs of authorisation, or Credential. A credential is an artefact which is associated with an electronic ID and is intended to be accessible only to the rightful owner of that electronic ID, for instance via a password.
For a private individual, an electronic ID is deemed to be authenticated if that person's identity can be verified and registered together with the electronic ID (authentication process). This authentication process is based on official ID documents that are checked and recorded when the credentials are issued. This ensures that the credentials are issued to the right person and that this person can subsequently be traced if necessary; the ID numbers on the official documents are a key element of the process.
Authenticated electronic IDs use credentials with good resistance to spyware and forgery. Passwords, mTAN and impersonal authenticator apps are not sufficient for providing authenticated electronic IDs in the eIAM context.
The governance and business requirements dictate whether an authenticated electronic ID is required for accessing a given resource.
Ein Identitätsanbieter oder Identity Provider (IdP) ist eine Systemeinheit, die Identitätsinformationen (elektronische Identitäten) für Principals - im eIAM-Kontext sind dies natürliche Personen - erstellt, pflegt und verwaltet und gleichzeitig Authentifizierungsdienste für darauf basierende Anwendungen innerhalb eines Verbands (Föderation) oder eines verteilten Netzwerks bereitstellt.
Identitätsanbieter bieten die Benutzerauthentifizierung als Dienst an. Anwendungen von vertrauenswürdigen Parteien, wie z. B. Webanwendungen, lagern den Schritt der Benutzerauthentifizierung an einen vertrauenswürdigen Identitätsanbieter aus. Eine solche Anwendung wird als föderiert bezeichnet, d.h. sie verlässt sich auf eine föderierte elektronische Identität.
Der eIAM-Trustbroker bezieht somit die elektronischen Identitäten somit bei Identitätsanbietern (Liste), übersetzt diese in Verbundsidentitäten und vermittelt Letztere an die Zielapplikationen. Die Verbundsidentität maskiert somit die technischen Identifikatoren der elektronischen Identität, die vom Identitätsanbieter kommen und hält die resultierenden Identifikatoren (Verbundsidentitäten) so gegenüber den Zielapplikationen stabil.
Die Bundesverwaltung hat ihre eigenen Identitätsanbieter an eIAM angeschlossen, einerseits für die elektronischen Identitäten der Mitarbeitenden (basierend auf der SG-PKI) und andererseits für die elektronischen Identitäten für natürliche Personen ausserhalb der Bundesverwaltung (für die Öffentlichkeit, darunter Bürgerinnen und Bürger, sowie Wirtschaftsvertreterinnen und -vertreter), die für eGovernment-Interaktionen mit der Bundesverwaltung authentifiziert werden müssen. Der von der Bundesverwaltung für die Öffentlichkeit zur Verfügung gestellte Identitätsanbieter heisst CH-LOGIN.
Externe Identitätsanbieter werden bei Bedarf an eIAM angeschlossen (cf. BYOI). Bei der Föderation mit eIAM werden die Credentials immer direkt beim Identitätsanbieter eingegeben, so dass nur dieser Kenntnis von diesen erhält.
Un fournisseur d'identités (IdP) est une unité du système qui crée, met à jour et gère les informations relatives aux identités (identités électroniques) pour des principaux des personnes physiques dans le contexte d'eIAM et met parallèlement à disposition des services d'authentification pour les applications qui reposent sur ces services au sein d'une fédération d'identités ou de réseaux distribués.
Les fournisseurs d'identités proposent l'authentification d'utilisateurs en tant que service. Et les applications dintervenants dignes de confiance (applications web notamment) sous-traitent létape d'authentification des utilisateurs à un fournisseur d'identités digne de confiance. Ce recours à un intervenant digne de confiance est qualifié de fédéré, car il s'appuie sur une identité électronique fédérée.
En l'occurrence, le courtier eIAM digne de confiance récupère les identités électroniques auprès de fournisseurs d'identités (liste), les traduit en identités fédérées, et les transmet aux applications cibles. L'identité fédérée masque ainsi les identifiants techniques de l'identité électronique provenant du fournisseur d'identités et fait en sorte que les identifiants qui en résultent (identités fédérées) restent ainsi constants pour les applications cibles.
L'administration fédérale a relié ses propres fournisseurs d'identités à eIAM, d'une part pour les identités électroniques de son personnel (au moyen de la SG PKI), et d'autre part pour les identités électroniques des personnes physiques en dehors de l'administration fédérale (le public, dont les citoyens et les représentants des milieux économiques) qui doivent être authentifiées pour pouvoir interagir avec elle dans le cadre de la cyberadministration. Le fournisseur d'identités que l'administration fédérale met à la disposition du public est appelé CH-LOGIN.
Des fournisseurs d'identités externes sont connectés à eIAM en fonction des besoins (cf. BYOI). Lors de la fédération des identités avec eIAM, les identifiants (credentials) sont toujours saisis directement au niveau du fournisseur d'identités. Ce dernier est donc le seul à en avoir connaissance.
An identity provider is a system unit that creates, stores and manages identity information (electronic IDs) for principals in the eIAM context, these are private individuals while simultaneously providing authentication services for applications based on eIAM within a federation or distributed network.
Identity providers offer user authentication as a service. Applications of trusted parties, such as web applications, outsource the user authentication step to a trusted identity provider. This use of a trusted party is known as federation, i.e. it uses a federated electronic ID.
Thus, eIAM's trust broker obtains the electronic IDs from identity providers (list) and translates them into federated identities, which it transmits to the target application. The federated ID thus keeps track of the technical identifiers of the electronic ID originating from the identity provider and ensures that the resulting identifiers (federated IDs) are stable vis-à-vis the target applications.
The Federal Administration has its own identity providers connected to eIAM, firstly for the electronic IDs of its employees (based on the SG PKI), and secondly for the electronic IDs of private individuals outside the Federal Administration (the general public, including citizens and business representatives) that have to be authenticated for eGovernment-related interactions with the Federal Administration. The identity provider that the Federal Administration has made available for the general public is called CH-LOGIN.
External identity providers are connected to eIAM as necessary (cf. BYOI). In the case of federation with eIAM, the credentials are always entered directly at the identity provider, so that only the provider knows what they are.
FED-LOGIN und CH-LOGIN sind zwei Login-Verfahren von eIAM.
Unter dem Begriff FED-LOGIN werden alle Loginmethoden zusammengefasst, welche den Einsatz der SG-PKI-basierten elektronischen Identität (eID) ermöglichen. Eine SG-PKI-basierte eID erhalten durch die Personaldienste der Bundesverwaltung ongeboardete Personen, sowie bestimmte Partner der Bundesverwaltung über deren Arbeitgeberprozesse (z. B. in kantonalen Verwaltungen). Merkmal ist, dass diese Personen eine Smartcard und/oder einen Mobile VDI-Zugang der Bundesverwaltung erhalten. Diese SG-PKI-basierte eID kann aus allen Netzen (inkl. Internet) mittels Smartcard und im Netz der Bundesverwaltung zusätzlich mittels Kerberos eingesetzt werden. Neu kann diese SG-PKI-basierte eID auch über Benutzername, Passwort und Zweitfaktoren wie mTAN, Authenticator App, Mobile ID und FIDO2 eingesetzt werden. Mit Mobile ID und FIDO2 resultiert eine qualitativ hochwertige Authentisierung, die aus jedem Netz, mit jedem Endgerät, also auch aus dem Internet, funktioniert. Diese Loginfaktoren, Passwort und Login-Zweitfaktoren, darunter die Mobile ID und FIDO2, registriert und verwaltet der Benutzer im Self-Service unter www.myaccount.eiam.admin.ch und zwar zwingend mittels Smartcard-Authentisierung oder, wenn keine Smartcard vorhanden ist, via ID/Pass-Verifikation online. Die Mobile ID als Zweitfaktor steht nicht sämtlichen mit SG-PKI ausgerüsteten Personen zur Verfügung. Zurzeit gilt aus kommerziell vertraglichen Gründen die Einschränkung auf interne und externe Mitarbeitende, die durch die Personaldienste der Bundesverwaltung ongeboardet wurden.
Das CH-LOGIN ist ein Identitätsprovider der Bundesverwaltung für natürliche Personen ohne FED-LOGIN. Damit werden natürliche Personen mit elektronischen Identitäten für die digitale Zusammenarbeit mit der Bundesverwaltung und deren Partner ausgestattet (CH-LOGIN FAQ). Sie können jedoch auch eine von Dritten herausgegebene elektronische Identität einsetzen (BYOI), wenn diese von eIAM zugelassen ist.
Hinweis: ID/Pass-Verifikation online als Smartcard-Ersatz und FIDO2 als Mobile ID-Alternative werden im Verlauf des Jahres 2022 eingeführt. ID/Pass-Verifikation online als Smartcard-Ersatz richtet sich an Mobile-VDI-User, welche nicht mit einer Smartcard ausgerüstet werden.
FED-LOGIN et CH-LOGIN: deux procédures de connexion deIAM
La notion FED-LOGIN regroupe toutes les procédures qui permettent d'utiliser l'identité électronique (eID) basée sur la SG PKI à des fins d'authentification. Les services du personnel de ladministration fédérale attribuent une eID basée sur la SG PKI aux collaborateurs enregistrés chez eux ainsi qu'à certains organes affiliés au moyen des processus de l'employeur (par ex. dans les administrations cantonales). Ces personnes reçoivent une carte à puce de l'administration fédérale ou un accès au service Mobile VDI. L'eID basée sur la SG PKI peut être utilisée sur tous les réseaux (y compris Internet) au moyen de la carte à puce et sur le réseau de l'administration fédérale au moyen de Kerberos. Dès à présent, l'eID basée sur la SG PKI peut également être utilisée avec un nom d'utilisateur, un mot de passe et deux facteurs d'authentification, tels que mTAN, Authenticator App, Mobile ID et FIDO2. Mobile ID et FIDO2 permettent une authentification d'excellente qualité, qui fonctionne sur chaque réseau, sur chaque terminal et donc aussi sur Internet. L'utilisateur saisit et gère lui-même ses facteurs d'identification, son mot de passe et ses deux facteurs d'authentification, dont Mobile ID et FIDO2, sur le portail libre-service www.myaccount.eiam.admin.ch. Pour accéder à ces informations, il doit s'authentifier au moyen de la carte à puce ou, s'il n'en a pas, au moyen d'une vérification ID/passeport en ligne. Pour accéder à ces informations, il doit s'authentifier au moyen de la carte à puce. Pour des raisons commerciales, Mobile ID pour l'authentification à deux facteurs n'est pas disponible pour toutes les personnes disposant d'une SG PKI; elle est actuellement limitée aux collaborateurs enregistrés auprès des services du personnel de l'administration fédérale, même s'il s'agit de collaborateurs externes.
CH-LOGIN est un service de ladministration fédérale fournissant une identité électronique aux personnes physiques qui nont pas de FED-LOGIN. Munies dun CH-LOGIN, ces personnes peuvent alors collaborer en ligne avec ladministration fédérale et ses organes affiliés (CH-LOGIN FAQ). Elles ont également la possibilité dutiliser une identité électronique délivrée par des tiers (BYOI), à condition que celle-ci soit agréée par le service eIAM.
Remarque: dans le courant de l'année 2022, la vérification ID/passeport en ligne remplacera la carte à puce, et le jeton FIDO2 sera introduit à titre de solution de rechange pour le certificat Mobile ID. Le remplacement de la carte à puce par une vérification ID/passeport en ligne s'adresse aux utilisateurs du service Mobile VDI qui ne possèdent pas de carte à puce.
FED-LOGIN and CH-LOGIN are two eIAM login procedures.
The term FED-LOGIN covers all login methods that enable the use of the SG-PKI-based electronic identity (eID). Individuals onboarded by Federal Administration HR and certain affiliates receive an SG-PKI-based eID via their employers' processes (e.g. in cantonal administrations). A defining characteristic is that these employees receive a smartcard and/or mobile VDI access from the Federal Administration. This SG-PKI-based eID can be used on all networks (including the internet) using this smartcard and additionally via Kerberos within the Federal Administration's network. This SG-PKI-based eID can now also be used with a user name, password and two-factor authentication such as mTAN, authenticator app, Mobile ID or FIDO2. Mobile ID and FIDO2 result in high-quality authentication that works on any network, with any device, i.e. also from the internet. Users register and manage these login factors, password and two-factor authentication factors, including their Mobile ID and FIDO2, themselves at www.myaccount.eiam.admin.ch. This must be done using smartcard authentication or, if no smartcard is available, via ID/passport verification online. The Mobile ID as a second factor is not available to all individuals equipped with SG-PKI; for commercial contract reasons, it is currently restricted to HR-onboarded employees of the Federal Administration, including HR-onboarded external employees of the Federal Administration.
CH-LOGIN is an identity provider of the Federal Administration for private individuals who do not have a FED-LOGIN. This allows private individuals to be equipped with electronic IDs for use in digital collaboration with Federal Administration employees and affiliates (CH-LOGIN FAQ). Such individuals can also use an electronic ID issued by third parties (BYOI), if they are approved by eIAM.
Note: ID/passport verification online as a smartcard replacement and FIDO2 as an alternative to Mobile ID will be introduced in the course of 2022. ID/passport verification online as a smartcard replacement is aimed at mobile VDI users who do not receive a smartcard.
Bring Your Own Identity (BYOI), sinngemäss «Bring deine eigene elektronische Identität», bietet die Möglichkeit, in IAM-Systemen wie dem eIAM der Bundesverwaltung elektronische Identitäten von Drittanbietern zu verwenden (siehe auch eIAM-Leistung 8); die Bundesverwaltung betrachtet diese als externe Identitätsprovider (IdP) (siehe IdP-Liste). Dazu muss rechtlich und technologisch das Vertrauen zwischen den Systemen etabliert werden, einerseits zwischen der Zielapplikation und dem IAM-System und andererseits dem IAM-System und dem externen Identitätsprovider; in der Bundesverwaltung sind die Grundlagen dazu die Vorgaben und IdP-Einstufungsverfahren der BK DTI.
BYOI ist für IAM-Systeme attraktiv, wenn auf dem Markt elektronische Identitäten hoher Qualität erhältlich sind, das heisst mit einem Abklärungsprozess bezüglich der Identität des Inhabers, starken Authentifikations- und Identitätsnachweismittel (Credentials) und einem gesicherten Lifecycle. Das IAM-System und die dazugehörige Organisation, in diesem Fall also eIAM und die Bundesverwaltung, müssen diese Leistungen nicht selbst erbringen. Für den Endbenutzer bringt BYOI den Vorteil, dass ein und dieselbe elektronische Identität in unterschiedlichen Kontexten eingesetzt werden kann.
BYOI ist bezüglich staatlich anerkannter elektronischer Identitäten zentral, da eben diese e-ID in verschiedenen Kontexten vom Inhaber selbst mitzubringen ist, sei es im privaten oder beruflichen Umfeld, und immer die handelnde natürliche Person repräsentiert.
Signifiant littéralement «fournir sa propre identité électronique», la méthode Bring Your Own Identity (BYOI) permet, dans un système de gestion des accès tel que l'eIAM de l'administration fédérale, d'utiliser les identités électroniques de fournisseurs FI tiers (liste), considérés par la Confédération comme des fournisseurs d'identités externes (FI) (voir aussi la prestation de l'eIAM 8). À cet effet, la confiance entre les systèmes doit être instaurée sur les plans juridique et technologique, d'une part, entre l'application cible et le système IAM et, d'autre part, entre le système IAM et le fournisseur externe d'identité. Les bases nécessaires à l'instauration de tels rapports de confiance sont, dans l'administration fédérale, les principes et la procédure d'évaluation des fournisseurs d'identités établis par la ChF TNI.
Si des identités électroniques de grande qualité sont disponibles sur le marché, le BYOI est intéressant pour les systèmes IAM, car ceux-ci et l'organisation concernée, en l'occurrence l'eIAM de l'administration fédérale, ne sont alors plus contraints de fournir de telles prestations. On parle de qualité élevée pour des identités électroniques lorsque le BYOI prévoit un processus de vérification de l'identité du titulaire et qu'il est doté d'instruments efficaces d'authentification et de vérification d'identité (credential) ainsi que d'un cycle de vie garanti. Pour l'utilisateur final, le BYOI a pour avantage de permettre à une seule et même identité électronique d'être utilisée dans des contextes différents.
Le BYOI joue un rôle central dans le domaine des identités électroniques reconnues par lÉtat, du fait que ces identités électroniques valables dans différents contextes privés ou professionnels, doivent être fournies par le titulaire lui-même et toujours représenter la personne physique concernée.
Bring your own identity (BYOI) refers to the possibility of using electronic identities from third-party providers in IAM systems such as the Federal Administration's eIAM. The Federal Administration considers these third parties (List) be external identity providers (IdPs) (see also eIAM service 8). In order to achieve this, legal and technological trust must be established between the systems. Firstly between the target application and the IAM system, and secondly between the IAM system and the external identity provider. In the Federal Administration, the basis for this is provided by the specifications and IdP classification procedures of the FCh DTI.
BYOI is attractive for IAM systems if high-quality electronic identities are available on the market. This is because the IAM system and the associated organisation, in this case eIAM and the Federal Administration, do not have to provide these services themselves. High quality means that the BYOI is equipped with an authentication process regarding the holder's identity, strong credentials and a secured lifecycle. For the end user, BYOI has the advantage that the same electronic identity can be used in different contexts.
BYOI is central to state-recognised electronic identities, since the eID for different contexts must be personally provided by the holder, whether in a private or professional context, and thus always represents an individual user.
Das Gast-Login ist ein von eIAM zur Verfügung gestelltes Pseudo-Login, das ausschliesslich auf der Eingabe einer Telefonnummer basiert, die einen Einmal-Code (mTAN) als Text- oder Sprachnachricht empfangen kann. Es ist dabei nicht notwendig, ein «Konto» wie z. B. ein CH-LOGIN anzulegen, da das Gast-Login eine «Fire-and-Forget»-Lösung ist und somit eher den Charakter eines erweiterten Captchas als eines Logins hat. Deshalb dürfen die Zielapplikationen keine Wiedererkennung von Gast-Logins implementieren, obwohl der technische Identifikator pro verwendete Telefonnummer konstant ist. Eine Wiedererkennung wäre z. B. dann gegeben, wenn ein Benutzer bei einem späteren Gast-Login Daten sehen könnte, die er bei einem früheren Gast-Login (mit derselben Telefonnummer) eingegeben hat.
Das Gast-Login ist nur verfügbar, wenn bei der Identitätsproviderwahl (IdP-Wahl) die Darstellungsart «CH-LOGIN first» anstelle der Kachel-Darstellung (vgl. Bilder weiter unten) erscheint. Welche Darstellung aktiv ist, wird für jede mit eIAM verknüpfte Zielapplikation beim BIT in Auftrag gegeben.
-
- CH-LOGIN first layout. Click on the image for explanations.
-
- Tiles layout. Click on the image for explanations.
La connexion en mode invité est une pseudo-connexion mise à disposition par eIAM, qui repose uniquement sur la saisie d'un numéro de téléphone pouvant recevoir un code unique (mTAN) sous forme de SMS ou de message vocal. En l'occurrence, il n'est pas nécessaire de créer un «compte» de type CH-LOGIN, parce que la philosophie de la connexion en mode invité correspond au mode «Fire and Forget» et que cette procédure s'apparente dès lors plutôt à un captcha amélioré quà une connexion. Telles sont les raisons pour lesquelles les applications cibles ne peuvent déduire aucune reconnaissance des connexions en tant qu'invité même si l'identifiant technique du numéro de téléphone utilisé reste constant. Il y aurait par exemple reconnaissance si un utilisateur qui se reconnecte en tant qu'invité était en mesure de voir des données qu'il a introduites lorsqu'il s'est connecté en mode invité dans le passé (avec le même numéro de téléphone).
La connexion en tant quinvité n'est disponible que lorsque le mode «CH-LOGIN first» est activé pour l'affichage de la sélection du fournisseur d'identités (sélection du FI), au lieu de la présentation sous forme de vignettes (voir les illustrations ci-dessous). L'affichage actif doit être commandé à l'OFIT pour chaque application cible reliée à eIAM.
-
- CH-LOGIN first layout. Click on the image for explanations.
-
- Tiles layout. Click on the image for explanations.
The guest login is a pseudo-login provided by eIAM; it relies on the user entering a telephone number that can receive a one-time code (mTAN) as a text or voice message. It is not necessary to register an account, unlike a CH-LOGIN, for example. The philosophy of a guest login is "fire and forget" more like an extended captcha than a login; for this reason, the target applications are not allowed to recognise guest logins more than once, even though the technical identifier remains the same for each telephone number used. Recognition would exist if, during a later guest login, a user were able to see the data that he/she had entered during an earlier guest login (with the same telephone number), for example.
The guest login is available only if the "CH-LOGIN first" layout is active for the presentation of the identity provider (IdP) selection, rather than the tile layout (see images below). The type of layout should be requested from the FOITT for each target application connected to eIAM.
-
- CH-LOGIN first layout. Click on the image for explanations.
-
- Tiles layout. Click on the image for explanations.
eIAMs myAccount ist eine Webapplikation, abrufbar unter www.myaccount.eiam.admin.ch, in welcher natürliche Personen die Daten ihres eIAM-Kontos verwalten können. Darin integriert ist die Verwaltung der Credantials des Identitätsproviders CH-LOGIN, der die Bundesverwaltung der Öffentlichkeit zur Verfügung stellt.
eIAMs myAccount erlaubt jedoch keinen Zugriff auf Daten (einschliesslich Credentials), die bei externen Identitätsprovidern gespeichert sind. Diese müssen direkt bei den externen Identitätsprovidern verwaltet werden.
L'application myAccount d'eIAM est une application web disponible sur www.myaccount.eiam.admin.ch, dans laquelle les personnes physiques gèrent les données de leur compte eIAM. Cette application intègre également la gestion des identifiants (credentials) du fournisseur d'identités CH-LOGIN, que l'administration fédérale met à la disposition du public.
En revanche, cette application ne permet pas d'accéder aux données (dont les identifiants) qui sont stockées auprès de fournisseurs d'identités externes, et qui doivent être mises à jour directement chez ces derniers.
eIAM's myAccount is a web application, accessed at www.myaccount.eiam.admin.ch, in which private individuals can manage their eIAM account data. Management of the CH-LOGIN identity provider credentials, which the Federal Administration makes available, is integrated into this account.
You cannot use eIAM's myAccount to access data (including credentials) that is stored at external identity providers; that has to be managed directly at the external IdP.
Der Begriff zweiter Loginfaktor bezeichnet das zusätzlich zum ersten Loginfaktor einzugebende Sicherheitsmerkmal (Credential). Der erste Loginfaktor ist häufig ein Passwort.
Dieser Artikel behandelt den zweiten Loginfaktor beim CH-LOGIN (siehe auch «Wie erhalte ich ein CH-LOGIN»): Für nicht verifizierte Identitäten können SMS-Codeversand (mTAN) und/oder Authenticator Apps verwendet werden. Für eine abgeklärte CH-LOGIN-Identität werden als zweiter Loginfaktor Vasco-Tokens eingesetzt (siehe CH-LOGIN LOA3).
Die Zielapplikation bestimmt, folgendes:
1. ob das CH-LOGIN eingesetzt werden kann,
2. ob dabei ein zweiter Loginfaktor einzusetzen ist,
3. ob das CH-LOGIN abgeklärt sein muss (LOA3).
Bestimmt die Zielapplikation, dass CH-LOGIN ohne Zweitfaktor verwendet werden kann, wird bei CH-LOGIN-Konten, bei denen ein Zweitfaktor hinterlegt ist, dieser trotzdem abgefragt, es sei denn, der Benutzer schaltet diese CH-LOGIN-Option in eIAMs myAccoun
Le terme second facteur didentification correspond au dispositif de sécurité à saisir (credential) en plus du premier facteur didentification, qui est souvent un mot de passe.
Cet article traite du second facteur didentification de CH-LOGIN (voir aussi «Comment puis-je obtenir un CH-Login»): pour les identités non vérifiées, une transmission de code par SMS (mTAN) et/ou des applications dauthentification peuvent être utilisées. Pour les identités CH-LOGIN vérifiées, des jetons Vasco peuvent être utilisés comme second facteur didentification (voir CH-LOGIN LOA3).
Lapplication cible détermine:
1. si le CH-LOGIN peut être utilisé;
2. si un deuxième facteur didentification doit être utilisé;
3. si le CH-LOGIN doit être vérifié (LOA3).
Si l'application cible détermine quil est possible de se connecter en utilisant CH-LOGIN sans deuxième facteur didentification, ce facteur sera tout de même demandé pour les comptes CH-LOGIN pour lesquels un deuxième facteur est enregistré, à moins que lutilisateur ne désactive cette option de CH-LOGIN dans myAccoun
The term "second login factor" describes the security credentials that have to be entered in addition to the first login factor. The first login factor is often a password.
This article looks at the second login factor in CH-LOGIN (see also «How do I obtain a CH-LOGIN?»). For unauthenticated IDs, a code can be sent via SMS (mTAN) or authenticator apps can be used. For authenticated CH-LOGIN IDs, Vasco tokens are used as the second login factor (see CH-LOGIN LOA3).
The target application stipulates:
1. Whether CH-LOGIN can be used
2. Whether a second login factor is required
3. Whether CH-LOGIN must be authenticated (LOA3)
If the target application determines that CH-LOGIN can be used to log in without a second login factor, it will still be requested for CH-LOGIN accounts for which a second factor is registered, unless the user deactivates this CH-LOGIN action via .. of eIAM («Only request second factor if target application explicitly requires it»).
Im Kontext des föderierten Identitätsmanagements werden Entitäten (natürliche Personen, juristische Personen, Systeme) mittels elektronischer Authentifikations- und Identitätsnachweise (Credentials) identifiziert. Die Identitätssicherung bietet der Partei, die Ressourcen anbietet, ein gewisses Mass an Sicherheit, dass die Credentials der Gegenpartei, mit der sie zur Durchführung einer Transaktion interagiert, tatsächlich zu dieser Entität gehören. Die Partei wird in diesem Zusammenhang als Relying Party (RP), als vertrauende Partei, bezeichnet.
In föderierten IAM-Systemen muss dieses Vertrauensverhältnis (Trust) zwischen der elektronischen Identität der handelnden Entität und der RP nicht nur etabliert, sondern auch verkettet werden. Dies weil die RP einem IAM-System vertrauen muss, das wiederum einem Identitätsanbieter (IdP) vertrauen muss, der häufig nicht Bestandteil des IAM-Systems ist. IdP, IAM-System und RP können dabei in jeder Hinsicht organisatorisch, geografisch und so weiter ganz unterschiedlich verortet sein.
Falls es sich bei der Entität um eine natürliche Person handelt, ist die Identitätssicherung die Ebene, auf der man sicher sein kann, dass der vorgelegte Authentifikations- und Identitätsnachweis ein Repräsentant für die natürliche Person ist, für die er ausgestellt wurde. Levels of Assurance (LOA) sind Vertrauensstufen, die mit einem Authentifikations- und Identitätsnachweis verbunden sind. Sie werden an der zugehörigen Technologie, den Prozessen und den Erklärungen zu Richtlinien und Praktiken gemessen. Diese Vertrauensstufen entsprechen der «Qualität der elektronischen Identität».
Es gibt verschiedene Einstufungsmodelle mit unterschiedlichen Skalen zur Bewertung der Qualität von elektronischen Identitäten sowie unterschiedlichen Bezeichnungen für die Qualitätsstufen. eIAM orientiert sich am Standard eCH-0170, der vier Qualitätsstufen mit der Bezeichnung Level of Assurance (LOA) 1 bis 4 verwendet.
Die IAM-Steuerung der BK DTI ist verantwortlich für die Etablierung des LOA-Modells von eCH in eIAM sowie das Mapping dieses Qualitätsmodells auf folgende Modelle:
- das QoA-Modell von eIAM (weak, normal, normalverified, strong, verystrong. Siehe auch Tabelle, nur intern & Use Cases)
- proprietäre Modelle von externen Identitätsprovidern
- den Standard ISO/IEC 29115
- die eIDAS Verordnung 910/2014
Die Qualität einer elektronischen Identität lässt sich in zwei Dimensionen unterteilen (siehe Video bei Minute 3:12): die Abklärungsqualität (Verifizierung), mit welcher die effektive Identität der dazugehörigen Entität festgestellt wird und die Stärke (Fälschungs- und Abhörsicherheit) der verwendeten Authentifikations- und Identitätsnachweise (Credentials). Wird der ganze Ausgabeprozess betrachtet, lässt sich eine dritte Qualitätsdimension erkennen, nämlich diejenige der Übergabe-Kopplung der Credentials zur Entität. Eine Kopplung der Credentials zu einer natürlichen Person ist beispielsweise bei persönlicher Übergabe mit gleichzeitiger Ausweiskontrolle besser als bei normalem Postversand dieser Credentials. Kommen biometrische Credentials zum Einsatz, gibt es die vierte Qualitätsdimension: die der Stärke der physischen Kopplung zur natürlichen Person (Vermeidung von Nachahmung).
Dans le contexte de la gestion fédérée des identités, les entités (personnes physiques ou morales, machines) sont identifiées au moyen dune attestation dautorisation électronique (credential). La garantie de lidentité permet à la partie qui fournit des ressources de sassurer avec plus ou moins de certitude que les credentials de la contrepartie avec laquelle elle collabore à lexécution dune transaction appartiennent réellement à lentité qui prétend les détenir. Dans ce contexte, la partie qui fournit des ressources est qualifiée de partie utilisatrice (relying party, RP).
Dans des systèmes fédérés de gestion des données didentification (IAM), cette relation de confiance (trust) ne doit pas seulement être établie entre lidentité électronique de lentité opérationnelle et la RP, mais doit lêtre dans lensemble de la chaîne. Cela tient au fait que la RP doit avoir confiance dans un système IAM qui doit lui-même pouvoir se fier à un fournisseur didentités (IdP) qui, bien souvent, ne fait pas partie du système IAM. LIdP, le système IAM et la RP peuvent être totalement différents à tout point de vue, que ce soit en termes dorganisation, de situation géographique ou autre.
Si lentité est une personne physique, la garantie de lidentité est le niveau auquel on peut être sûr que le credential présenté correspond bien à la personne physique à laquelle il a été délivré. Les assurance levels sont les niveaux de confiance associés à un credential. Ils sont définis sur la base de la réponse que les technologies, processus et déclarations quils contiennent apportent aux exigences des directives et des travaux pratiques. Ces niveaux de confiance attestent la «qualité de lidentité électronique».
Il existe différents modèles et échelles dévaluation de la qualité des identités électroniques et diverses façons de désigner les niveaux de qualité. Le service eIAM se fonde à cet égard sur la norme eCH-0170, qui comprend quatre niveaux de qualité pour les levels of assurance (LOA).
Le service de pilotage de lIAM de la ChF TNI a compétence pour intégrer le modèle de LOA de lassociation eCH dans le service eIAM et pour accorder ce modèle de qualité avec les modèles suivants:
- le modèle QoA niveaux de l'eIAM (weak, normal, normalverified, strong, verystrong. Voir aussi Tableau, uniquement interne & Use Cases)
- modèles exclusifs de fournisseurs didentités externes;
- norme ISO/IEC 29115;
- règlement eIDAS 910/2014.
La qualité dune identité électronique comprend deux dimensions (cf. vidéo à la minute 3:13): la qualité de vérification, qui permet de vérifier lidentité réelle de lentité, et la fermeté (protection contre la falsification et linterception) des credentials utilisés. Lanalyse de lensemble du processus démission révèle une troisième dimension, à savoir le couplage de transmission avec lentité. Lorsquil sagit de remettre personnellement des credentials à une personne physique et vérifier en même temps lidentité de celle-ci, il est préférable de procéder à un couplage au lieu dopter pour un envoi postal ordinaire. Lutilisation de credentials biométriques fait apparaître une quatrième dimension, celle de la fermeté du couplage physique avec la personne (prévention des reproductions).
In federated IAM systems, this trust relationship (trust) must not only be established between the electronic ID of the transacting entity and the RP, but must also be integrated into a chain. This is because the RP needs to trust an IAM system, which in turns needs to trust an identity provider (IdP), which is often not part of the IAM system. The IdP, the IAM system and the RP can be in completely different places, in all senses of the word: organisationally, geographically, etc.
If the entity is a private individual, identity assurance provides others with a level of assurance that the presented credentials represent the individual for whom they were issued. Assurance levels are levels of trust linked to credentials, and are measured against the associated technology, processes and declarations on rules and practices. These assurance levels denote the "quality of the electronic ID".
There are different rating models with different quality scales for electronic IDs and different designations for quality levels. eIAM uses the eCH-0170 standard, with four quality designations for the level of assurance (LOA).
The IAM management of the FCh DTI is responsible for setting up the LOA model of eCH in eIAM, and for mapping this quality model onto the following models:
- the QoA model of eIAM (weak, normal, normalverified, strong, verystrong. See also Table, internal only & Use Cases)
- proprietary models of external IdPs
- ISO/IEC standard 29115
- eIDAS Regulation 910/2014
The quality of an electronic ID can be broken down into two dimensions (see video, minute 3:11): the request quality with which the effective identity of the associated entity has been verified, and the robustness (against being spoofed and hacked) of the credentials presented. If the entire issuance process is evaluated, a third quality dimension comes into play: the handover connection to the entity. For example, when connecting the credentials to a private individual, a personal handover in which the person's ID is examined is better than sending the credentials by post. If biometric credentials are used, there is a fourth quality dimension: the robustness of the physical connection to the private individual (to prevent imitation).
FIDO und Mobile ID sind die Hardcrypto-Tokens, welche via CH-LOGIN und FED-LOGIN eingesetzt werden können; im FED-LOGIN kann auch die Smartcard der Bundesverwaltung als Hardcrypto-Token eingesetzt werden. eIAMs CH-LOGIN kann aktuell auch noch mit Hardsync-Tokens (Vasco alias Digipass Authenticator) arbeiten (veraltet).
Diese Tokens fungieren als Loginzweitfaktoren und sind sicherer als die Loginzweitfaktoren SMS mTAN und Authenticator Apps. Erörterung zum Einsatz dieser Tokens.
Mobile IDDie Mobile ID ist ein Zertifikat, das auf den SIM-Karten (Subscriber Identity Module, inkl. eSIM) der (derzeit nur Schweizer) Mobiltelefonieanbieter gespeichert ist (Anbieter siehe https://www.mobileid.ch). Sie kann als Credential eingesetzt werden und wird vorgängig durch die Benutzenden im Self-Service auf www.myaccount.eiam.admin.ch registriert. Das Zielsystem, das einen Authentifikations-/Identitätsnachweis anfordert und dafür die Mobile ID akzeptiert, sendet eine dedizierte Pushmeldung an das Mobilgerät, das die entsprechende SIM-Karte verwendet. Der Endbenutzer, die Endbenutzerin muss daraufhin auf diesem Mobilgerät ein Passwort eingeben, um dem anfragenden Zielsystem die Mobile ID zu übermitteln.
Der Einsatz der Mobile ID als Credential führt nicht automatisch zu einer verifizierten elektronischen Identität (LOA3); zwar ist die Credentialqualität der Mobile ID (Zertifikat) für ein Level of Assurance 3 ausreichend, aber der Prozess zur Überprüfung der Identität des Endbenutzers, der Endbenutzerin bei der Ausgabe der SIM-Karte ist ungenügend. Deshalb muss zusätzlich eine ID/Pass-Verifikation online durchgeführt werden.
eIAM nutzt ab 2021 die Mobile ID als zweiten Loginfaktor für das FED-LOGIN, in Kombination mit dem Abklärungsprozess der SG-PKI, wodurch die Mobile ID als verifizierte elektronische Identität verwendet werden kann. Dies gilt jedoch ausschliesslich für Mitarbeitende der Bundesverwaltung.
eIAM nutzt ab 2022 die Mobile ID als zweiten Loginfaktor auch für das CH-LOGIN, in Kombination mit der ID/Pass-Verifikation online service.
FIDO-Tokens sind Datenträger, z. B. in Form eines USB-Sticks, enthaltend kryptografisches Material. FIDO-Tokens werden durch die Endbenutzer im Elektronikhandel selber beschafft. FIDO-Tokens können als Credential eingesetzt werden und vorgängig durch die Benutzenden im Self-Service auf www.myaccount.eiam.admin.ch registriert. Das Zielsystem, das ein Credential anfordert und dafür FIDO-Tokens akzeptiert, verifiziert das kryptografische Matierial des Tokens.
Der Einsatz von FIDO-Tokens als Credential führt nicht automatisch zu einer verifizierten elektronischen Identität (LOA3); zwar ist die Credentialqualität der FIDO-Tokens für ein Level of Assurance 3 ausreichend, aber es braucht zusätzlich einen Abklärungsprozess. Deshalb muss zusätzlich eine ID/Pass-Verifikation online durchgeführt werden.
eIAM unterstützt FIDO-Tokens ab Sommer 2022.
FIDO et Mobile ID sont des jetons cryptographiques matériels que l'on peut utiliser avec CH-LOGIN et FED-LOGIN. Pour l'authentification au moyen de FED-LOGIN, il est également possible d'utiliser la carte à puce de l'administration fédérale en tant que jeton cryptographique matériel. CH-LOGIN d'eIAM permet encore l'utilisation de jetons synchronisés matériels (Vasco, ou Digipass Authenticator).
Ces jetons servent de seconds facteurs d'authentification et sont plus sûrs que les SMS mTAN et les applications d'authentification. Explication relative à l'utilisation de ces jetons.
Mobile IDLe certificat Mobile ID est enregistré seulement sur les cartes SIM (Subscriber Identity Module, y c. cartes SIM intégrées) des opérateurs de téléphonie mobile (suisses uniquement à l'heure actuelle). Pour la liste des opérateurs, voir https://www.mobileid.ch. Enregistré au préalable par l'utilisateur dans le portail libre-service www.myaccount.eiam.admin.ch, le certificat Mobile ID peut être utilisé comme identifiant. Le système cible qui exige des informations d'identification et accepte ce certificat envoie une notification automatique dédiée vers l'appareil mobile qui utilise la carte SIM en question. L'utilisateur final doit ensuite saisir un mot de passe sur son appareil mobile pour transmettre son certificat Mobile ID au système cible.
L'utilisation de ce certificat comme identifiant n'implique pas automatiquement la vérification de l'identité électronique (LOA3); si la qualité de l'identifiant du certificat Mobile ID satisfait au niveau d'assurance 3, le processus de vérification de l'identité de l'utilisateur final lors de l'émission de la carte SIM n'est pas suffisant. C'est pourquoi il est nécessaire de procéder en outre à une vérification ID/passeport en ligne.
À partir de 2021, eIAM utilise le certificat Mobile ID en tant que second facteur d'authentification pour FED-LOGIN, en sus du processus de vérification de la SG-PKI, ce qui permet d'employer le certificat Mobile ID pour les identités électroniques vérifiées. Cela ne concerne toutefois que le personnel de l'administration fédérale.
À partir de 2022, eIAM utilise le certificat MOBILE ID en tant que second facteur d'authentification pour CH-LOGIN également, en sus du service d'vérification ID/passeport en ligne.
Les jetons FIDO sont des supports de données qui peuvent prendre la forme d'une clé USB et qui contiennent du matériel cryptographique. Les utilisateurs finals acquièrent eux-mêmes les jetons FIDO dans le commerce électronique. Enregistrés au préalable par l'utilisateur dans le portail libre-service www.myaccount.eiam.admin.ch, les jetons FIDO peuvent être utilisés comme identifiants. Le système cible qui exige un identifiant et accepte les jetons FIDO vérifie le matériel cryptographique du jeton.
L'utilisation de jetons FIDO comme identifiants n'implique pas automatiquement la vérification de l'identité électronique (LOA3); si la qualité de l'identifiant des jetons FIDO satisfait au niveau d'assurance 3, une vérification de l'identité reste nécessaire. C'est pourquoi il est nécessaire de procéder en outre à une vérification ID/passeport en ligne.
eIAM supportera les jetons FIDO à partir de l'été 2022.
FIDO and Mobile ID are the hardware cryptographic tokens that can be used via CH-LOGIN and FED-LOGIN. Additionally, the Federal Administration's smart card can be used as a hardware cryptographic token for FED-LOGIN. At present, eIAM's CH-LOGIN can still work with (obsolete) hardware sync tokens (VASCO, aka DIGIPASS authenticator) as well.
These tokens act as second login factors and are more secure than mTAN messages and authenticator app second login factors. Explanation on the use of these tokens.
Mobile IDMobile ID is a certificate stored on the SIMs (subscriber identity modules, incl. eSIMs) of (currently only Swiss) mobile telephony providers (see https://www.mobileid.ch for providers). It can be used as a credential and is registered in advance by users in the self-service section at www.myaccount.eiam.admin.ch. The target system that requests a credential and accepts Mobile ID for that purpose sends a dedicated push notification to the mobile device that is using the corresponding SIM. The end user then has to enter a password on that mobile device in order to transmit the Mobile ID credential to the requesting target system.
The use of Mobile ID as a credential does not automatically result in an authenticated electronic identity (LOA3); although the quality of the Mobile ID credential (certificate) is sufficient for level of assurance 3, the process for verifying the identity of the end user when the SIM card is issued is insufficient. Therefore, an ID/passport verification online also has to be carried out.
Effective from 2021, eIAM has been using Mobile ID as a second login factor for FED-LOGIN, in combination with the SG PKI authentication process, which means that Mobile ID can be used as an authenticated electronic identity. However, this applies solely to Federal Administration employees.
From 2022, eIAM will also use Mobile ID as a second login factor for CH-LOGIN, in combination with the ID/passport verification online service.
FIDO tokens are data carriers, e.g. in the form of a flash drive, that contain cryptographic material. FIDO tokens are procured from electronics retailers by the end users themselves. FIDO tokens can be used as credentials and registered in advance by users in the self-service section at www.myaccount.eiam.admin.ch. The target system that requests a credential and accepts FIDO tokens for that purpose verifies the cryptographic material of the token.
The use of FIDO tokens as credentials does not automatically result in an authenticated electronic identity (LOA3); although the quality of the FIDO token credential is sufficient for level of assurance 3, an additional authentication process is needed. Therefore, an ID/passport verification online also has to be carried out.
eIAM will support FIDO tokens from summer 2022.
Eine elektronische Identität gilt als abgeklärt, wenn ein amtlicher Lichtbildausweis des Inhabers der elektronischen Identität überprüft, registriert und dem Inhaber korrekt zugeordnet wird.
Das CH-LOGIN bietet hier für die ID/Pass-Verifikation online. Der Benutzer, die Benutzerin loggt sich mittels CH-LOGIN auf www.myaccount.eiam.admin.ch ein und führt die online ID/Pass-Verifikation durch. Die ID/Pass-Verifikation online ist ein Videotelefonat, in welchem ein externer Dienstleister den amtlichen Lichtbildausweis und die Person kontrolliert. Die erhobenen Daten fliessen zurück ins BIT. Ab jetzt gilt das CH-LOGIN als abgeklärt, gültig 5 Jahre für alle Anwendungen der Bundesverwaltung. Die ID/Pass-Verifikation online kostet CHF 45.00 (incl. VAT) und wird vom Endbenutzenden im Moment des Eintritts in den Prozess online bezahlt (Zahlungsmittel: MasterCard, Visa, ApplePay, GooglePay, SamsungPay, Twint, PostFinance Card, PostFinance E-Finance, American Express, PayPal oder per Voucher-Code der Bundesverwaltung).
In bestimmten Fällen muss zusätzlich ein speziell gesicherter Login-Zweitfaktor (Hardcrypto-Token) eingesetzt werden, eIAM setzt dabei auf FIDO und Mobile ID, für welche gilt, dass der Endbenutzer, die Endbenutzerin einen davon selber mitbringt. FIDO-Tokens sind im Elektronikhandel erhältlich, die Mobile ID ist auf den meisten Schweizer SIM und eSIM vorinstalliert. FIDO und Mobile ID werden im Self-Service über www.myaccount.eiam.admin.ch mit dem CH-LOGIN verbunden.
Wann abgeklärte elektronische Identitäten mit und ohne Hardcryptotoken einzusetzen sind, ist auf der Seite Identities QoA 40, 50 & 60 beschrieben.
eIAM unterstützt zurzeit auch noch Vasco-Tokens für abgeklärte elektronische Identitäten. Dieses Verfahren soll nicht mehr weiterverbreitet werden. Es ist im untenstehenden Abschnitt beschrieben.
Veraltet: Vasco-TokensInterner Link: Informationen für LB zu Bestellprozess und Anleitung der Endbenutzenden.
Ein Vasco-Token ist ein batteriebetriebenes Gerät in der Grösse eines Feuerzeugs, welches in regelmässigen Abständen eine neue Zufallszahl anzeigt. Diese Zahl muss beim Login als zweiter Loginfaktor angegeben werden, man spricht von einem Einmal-Passwort (One-Time-Password (OTP)).
Beim Abklärungsprozess bei der Übergabe des Vasco-Tokens wird die Wohnadresse, sowie ein amtliches Ausweispapier des Empfängers kontrolliert und registriert. Im Inland wird dafür der Aushändigungs-Service der Schweizerischen Post genutzt und für das Ausland stellt das BIT den Service zur Verfügung. Die Applikationsverantwortlichen kommen mit dem Abklärungsprozess nicht in Kontakt. Diese Abklärung etabliert das LOA3 für die zukünftig mit diesem Vasco-Token eingesetzte elektronischen Identität, im vorliegenden Fall eine CH-LOGIN-Identität.
Die betroffene CH-LOGIN-Identität kann weiterhin mit tieferen Levels of Assurance eingesetzt werden (für Zielapplikationen, die dies zulassen), dort also auch mit den Loginfaktoren Passwort, SMS-Code (mTAN), Authenticator Apps. Die Nutzung einer Zielapplikation mit einem Level of Assurance höher als die von der Applikation verlangte, ist in diesem Zusammenhang immer möglich.
Die aus dem vorerwähnten Abklärungsprozess gewonnenen Daten werden ausserhalb von eIAM gespeichert und stehen für Regress-Situationen zur Verfügung. Die Daten im CH-LOGIN-Konto werden weiterhin vom CH-LOGIN-Inhaber gepflegt und haben somit weiterhin den Status selbstdeklariert und nicht abgeklärt.
Benötigt eine Applikation von eIAM Benutzerlogins mit der Qualität LOA3 in der Form CH-LOGIN mit Vasco-Token, muss die entsprechende eIAM-Konfiguration für diese Applikation bestellt werden, bezeichnet mit «CH-LOGIN strong». Die betroffenen Endbenutzer müssen von den Applikationsverantwortlichen instruiert werden, ein CH-LOGIN zu registrieren (siehe «Wie erhalte ich ein CH-LOGIN») oder mit einem bereits bestehenden CH-LOGIN auf der Seite myAccoun
Wichtig ist, dass bei dieser Instruktion eine Kontakt-E-Mailadresse im Bestellformular angegeben wird. Als Kontakt-E-Mailadresse muss die mit dem BIT vereinbarte Approver-E-Mail verwendet werden. Der Approver erhält die Vasco-Token-Bestellung und löst diese über Remedy aus (oder lehnt sie ab). Die Kosten für den Vasco-Token trägt die bestellende Verwaltungseinheit. Der Endbenutzer erhält den Vasco-Token mittels dem vorerwähnten Abklärungsprozess und muss die Seriennummer des Vasco-Tokens auf der Seite myAccoun
Ein so mit dem CH-LOGIN verbundener Vasco-Token kann für sämtliche CH-LOGIN-konsumierenden Applikationen verwendet werden. Es ist also pro CH-LOGIN-Identität maximal ein Vasco-Token im Einsatz.
Vasco-Token der Bundesverwaltung, die bisher noch nicht für CH-LOGIN genutzt wurden, können häufig auch zusätzlich in eIAM genutzt werden. Der Vasco-Token wird dazu in eIAMs myAccoun
Afin qu'une identité électronique puisse être considérée comme vérifiée, une pièce d'identité officielle munie d'une photographie du détenteur de l'identité électronique doit avoir été contrôlée, enregistrée, et son détenteur doit être correctement identifié.
À cet effet, CH-LOGIN permet une vérification ID/passeport en ligne. L'utilisateur se connecte sur www.myaccount.eiam.admin.ch au moyen de CH-LOGIN et procède à la vérification ID/passeport en ligne. Cette dernière consiste en un appel vidéo lors duquel un prestataire externe contrôle l'identité d'une personne qui lui présente une pièce d'identité officielle munie d'une photographie. Les données obtenues retournent à l'OFIT. La connexion par CH-LOGIN est validée pour cinq ans, pour toutes les applications de l'administration fédérale. La vérification ID/passeport en ligne coûte CHF 45.00 (incl. VAT) et est payée en ligne par l'utilisateur final au moment où il entre dans le processus (moyens de paiement : MasterCard, Visa, ApplePay, GooglePay, SamsungPay, Twint, PostFinance Card, PostFinance E-Finance, American Express, PayPal ou par Voucher-Code de l'administration fédérale).
Dans des cas particuliers, il est nécessaire d'utiliser en plus un second facteur d'authentification sécurisé (jeton cryptographique matériel). Pour eIAM, il s'agit de FIDO et du certificat Mobile ID, que l'utilisateur final doit lui-même fournir. Les jetons FIDO sont disponibles dans le commerce électronique, tandis que le certificat Mobile ID est préinstallé dans la plupart des cartes SIM (intégrées ou non) suisses. FIDO et le certificat Mobile ID sont liés à CH-LOGIN dans le portail libre-service www.myaccount.eiam.admin.ch.
La page Identités QoA 40, 50 et 60 explique quand utiliser une identité électronique vérifiée avec ou sans jeton cryptographique matériel.
Pour le moment, eIAM supporte aussi les jetons Vasco pour les identités électroniques vérifiées. La procédure ne doit pas être reprise plus largement, comme décrit dans le paragraphe ci-dessous.
Dépassés: jetons VascoLien interne: Informations destinées aux BP sur le processus de commande et guide pour les utilisateurs finals.
Un jeton Vasco est un dispositif alimenté par une pile de la taille d'un briquet, qui affiche un nouveau numéro aléatoire à intervalles réguliers. Ce numéro doit être saisi comme deuxième facteur d'identification lors de l'ouverture d'une session; c'est ce que l'on appelle un mot de passe à usage unique (one-time password, OTP).
Lors de la remise du jeton Vasco, une pièce d'identité officielle du destinataire est contrôlée et enregistrée, de même que l'adresse de résidence. En Suisse, un service de distribution de la Poste est utilisé pour la remise; pour les pays étrangers, l'OFIT dispose d'un service de livraison. Les responsables de l'application ne participent pas au processus de vérification. C'est le LOA3 qui établit la vérification de l'identité électronique utilisée à l'avenir avec le jeton Vasco, en l'occurrence une identité CH-LOGIN.
L'identité CH-LOGIN concernée peut être utilisée avec des niveaux d'assurance inférieurs (pour les applications cibles qui le permettent), c'est-à-dire là aussi avec des facteurs d'identification tels qu'un mot de passe, un SMS d'authentification (mTAN) ou des applications d'authentification. L'utilisation d'une application cible présentant un niveau d'assurance supérieur à celui requis par l'application est toujours possible dans ce contexte.
Les données obtenues dans le cadre du processus de vérification susmentionné sont enregistrées hors d'eIAM et sont disponibles dans les cas de recours. Les données du compte CH-LOGIN resteront chez leur propriétaire et garderont le statut auto-déclaré et non vérifié.
Si une application nécessite un compte d'utilisateur d'eIAM avec la qualité LOA3 sous la forme CH-LOGIN avec un jeton Vasco, la configuration eIAM correspondante, appelée «CH-LOGIN strong», doit être commandée pour cette application. Les responsables de l'application doivent renseigner les utilisateurs finals sur l'enregistrement de CH-LOGIN (voir «Comment puis-je obtenir un CH-LOGIN»). Si les utilisateurs disposent déjà d'un compte CH-LOGIN, ils doivent commander un jeton Vasco sur la page myAccoun
Il est important que le responsable d'application précise l'adresse électronique de contact dans le formulaire de commande. L'utilisateur final doit saisir l'adresse électronique de l'approbateur convenue avec l'OFIT en tant qu'adresse de contact. L'approbateur reçoit la commande de jeton Vasco et la saisit dans Remedy (ou la rejette). L'unité administrative qui passe la commande assume les frais relatifs au jeton Vasco. L'utilisateur final reçoit le jeton Vasco au moyen du processus de vérification susmentionné et enregistre le numéro de série du jeton Vasco sur la page myAccoun
Un jeton Vasco lié à CH-LOGIN peut être utilisé pour toutes les applications recourant à CH-LOGIN. Un jeton Vasco au maximum peut donc être utilisé par identité CH-LOGIN.
Les jetons Vasco de l'administration fédérale qui n'ont pas encore servi pour CH-LOGIN peuvent souvent être utilisés également dans eIAM. À cet effet, le jeton Vasco doit être enregistré sur la page myAccoun
An electronic identity is considered authenticated when an official photo ID of its holder has been verified, registered and correctly assigned to the holder.
CH-LOGIN offers ID/passport verification online for this purpose. The user logs in using CH-LOGIN at www.myaccount.eiam.admin.ch and carries out the ID/passport verification online. The ID/passport verification online is a video call during which an external service provider checks the official photo ID and the person. The data collected is transmitted to the FOITT. Thereafter, the CH-LOGIN in question is deemed to be authenticated; this is valid for 5 years for all Federal Administration applications. The ID/passport verification online costs CHF 45.00 (incl. VAT) and is paid for online by the end user at the moment they enter the process (payment methods: MasterCard, Visa, ApplePay, GooglePay, SamsungPay, Twint, PostFinance Card, PostFinance E-Finance, American Express, PayPal or by voucher code from the Federal Administration).
In certain cases, a particularly secure second login factor (hardware cryptographic token) also has to be used. eIAM uses FIDO and Mobile ID, whereby end users are required to bring one of these themselves. FIDO tokens are available from electronics retailers; Mobile ID is pre-installed on most Swiss SIMs and eSIMs. FIDO and Mobile ID are linked to the relevant CH-LOGIN in the self-service section at www.myaccount.eiam.admin.ch.
For information on when authenticated electronic identities are to be used with and without hardware cryptographic tokens, see the page on QoA 40, 50 and 60 identities.
At the moment, eIAM also supports VASCO tokens for authenticated electronic identities. This process is to be discontinued. It is described in the section below.
Obsolete: VASCO tokensInternal link: Information on the ordering process for service procurers and guidance for end users.
A VASCO token is a battery-operated device the size of a cigarette lighter which displays a new randomly generated number at regular intervals. This number has to be entered as the second login factor; this is known as a one-time password (OTP).
During the verification process when the VASCO token is handed over, the recipient's home address and an official identity document are checked and registered. In Switzerland, the delivery service of Swiss Post is used for this purpose, while the FOITT provides the service for foreign countries. The people in charge of the application do not come into contact with the authentication process. This authentication establishes LOA3 for the electronic identity that will be used in conjunction with this VASCO token in the future in this case, a CH-LOGIN ID.
The CH-LOGIN ID concerned can continue to be used with lower levels of assurance (for target applications that allow this), i.e. with login factors such as passwords, text message codes (mTANs) and authenticator apps. The use of a target application with a level of assurance higher than that required by the application is always possible in this context.
The data collected from the authentication process described above is stored outside eIAM and is available for situations in which the user needs to be traced. The data in the CH-LOGIN account continues to be managed by the CH-LOGIN owner and thus retains the status self-authenticated and unauthenticated.
If an application needs eIAM for user logins with LOA3 in the form of a CH-LOGIN with VASCO token, the corresponding eIAM configuration for this application has to be requested using the descriptor "CH-LOGIN strong". Those responsible for the application must instruct the relevant end users to register a CH-LOGIN (see "How do I obtain a CH-LOGIN?") or to order a VASCO token on the myAccoun
It is important that a contact email address be provided in the order form with these instructions. The approver email agreed with the FOITT must be used as the contact email address. The approver receives the VASCO token order and carries it out via remedy action (or rejects it). The cost of the VASCO token is borne by the administrative unit that placed the order. The end user receives the VASCO token by means of the aforementioned authentication process and must register the VASCO token's serial number on the myAccoun
A VASCO token linked to CH-LOGIN in this way can be used for all applications that use CH-LOGIN. A maximum of one VASCO token is thus used per CH-LOGIN ID.
Federal Administration VASCO tokens that have not yet been used for CH-LOGIN can often be used additionally in eIAM as well. The VASCO token is registered in eIAM's myAccoun
Ein eIAM-Mandant, oft auch als Accessmandant bezeichnet, 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 eIAM-Mandanten ist dem Fach überlassen, der häufigste Schnitt ist 1 VE (Amt) = 1 Mandant. Für Grossprojekte oder Applikationen mit Middleware-Charakter kann die Formel 1 Mandant pro Grossprojekt resp. Middleware sinnvoll sein. Die Tarifierung erfolgt pro eIAM-Accessmandant.
Un mandant eIAM, souvent également appelé «mandant daccès», est un espace de travail dédié à lattribution des droits qui, au besoin, peut être subdivisé en unités (units) afin dy déléguer à linterne ou à lexterne des activités dattribution des droits.
Le découpage dun mandant eIAM est laissé au libre choix de lunité administrative; le découpage le plus fréquent est 1 UA (office) = 1 mandant. Pour les grands projets ou les applications à caractère dintergiciels, la formule «1 mandant par grand projet ou intergiciel» peut savérer judicieuse. La tarification seffectue par mandant daccès eIAM.
An eIAM client, often called an access client or mandator or tenant, is a dedicated workspace for assigning permissions, and can be subdivided into units for the purpose of delegating rights in these units to internal and external users.
The scope of an eIAM client is defined by the technical specialists, with the most common being 1 AU (administrative unit) = 1 client. For large projects or middleware applications, the formula of 1 client per large project or middleware can be a logical choice. Tariffs are calculated for each eIAM access client.
Ein RP-PEP (Reverse Proxy-Policy Enforcement Point) ist ein Gateway, durch welchen sämtliche eingehenden und ausgehenden Daten zu/von einer angeschlossenen Applikation geschleust werden. Im Gegensatz zu einer Web Application Firewall (WAF), kontrolliert der RP-PEP nicht nur die Daten, sondern auch die Authentizität der sendenden und empfangenden Subjekte.
eIAM stellt für intern betriebene Applikationen RP-PEPs zur Verfügung. Soll dieser zusätzliche Schutz genutzt werden, muss die Zielapplikation reverseproxyfähig sein. Der Einsatz eines RP-PEP ist jedoch nur in bestimmten Netzzonen und bei speziellen Schutzbedarfssituationen obligatorisch.
Ist die Zielapplikation extern gehostet, können beim externen Hoster unabhängig von eIAM RP-PEPs eingesetzt werden, falls die Situation dies erfordert.
Un RP-PEP (Reverse Proxy-Policy Enforcement Point) est une passerelle par laquelle transitent toutes les données entrantes et sortantes depuis/vers une application reliée. À linverse dun pare-feu dapplications web (web application firewall, WAF), le RP-PEP contrôle non seulement les données, mais aussi lauthenticité des expéditeurs et des destinataires.
eIAM met à disposition des RP-PEP pour les applications exploitées à linterne. Pour pouvoir utiliser cette protection supplémentaire, il faut que lapplication-cible soit compatible avec un proxy inverse (reverse proxy). Toutefois, lutilisation dun RP-PEP nest obligatoire que dans des zones réseaux précises et en cas de besoins particuliers de protection.
Si lapplication-cible est hébergée à lexterne, il est possible dutiliser des RP-PEP indépendamment deIAM auprès de lhébergeur externe si la situation lexige.
A PEP (policy enforcement point) is a gateway through which all incoming and outgoing data for a connected application is routed. In contrast to a web application firewall (WAF), the PEP checks not just the data, but also the authenticity of the sender and recipient.
In eIAM, PEPs for internally run applications are included in the tariff. If this results in additional protection being necessary, the target application must have reverse proxy capability. However, the use of a PEP is mandatory only in certain network zones and for certain protection scenarios.
If the target application is externally hosted, the external host can use PEPs independently of eIAM, if required.
eIAM bietet delegiertes Management an. In anderen IAM-Systemen wird diese Funktionalität als delegierte Rechtezuweisung, delegierte Benutzerverwaltung oder delegierte Administration bezeichnet.
Das delegierte Management findet nicht in der IDM-Adminapplikation statt, sondern in einem dedizierten Web-User Interface von eIAM. Dieses kann auch durch die Zielapplikation über eine Schnittstelle automatisch bespielt werden (Remote-Delegated-Management RDM). Um dieses nutzen zu können, müssen Sie das delegierte Management von eIAM einmalig beim BIT für Ihren eIAM-Accessmandanten aufschalten lassen, wenden Sie sich an Ihren Account Manager im BIT.
Um die Delegierung an eine oder mehrere interne oder externe Organisationseinheiten vornehmen zu können, werden durch Sie in eIAM sogenannte Units eröffnet, welche diese Organisationseinheiten repräsentieren. Die Units sind also eine Strukturierung Ihres eIAM-Accessmandanten. Pro Unit laden Sie, ebenfalls im vorerwähnten Web-User Interface, mindestens einen delegierten Manager ein. Der delegierte Manager kann nun selbständig innerhalb seiner Unit «seine» Benutzer einladen und berechtigen. Die Eigenschaften der Unit, sprich welche Rollen und Attribute für welche Zielapplikationen darin vergeben werden können, stellen Sie als Unit-Eröffner selber ein, ebenso, ob die delegierten Manager selber Sub-Units eröffnen und delegieren können.
Die zentrale Eigenschaft des delegierten Managements sind die vorerwähnten Einladungen, also das Einladen der delegierten Manager und das Einladen der Benutzer durch die delegierten Manager. Das Einladeverfahren bringt den Vorteil, dass die Benutzer angelegt und auch bereits berechtigt werden können, bevor man deren elektronische Identität kennt. Die Benutzer erhalten einen Onboarding Code, z. B. per E-Mail, welchen Sie mit einer adäquaten elektronischen Identität ihrer Wahl einlösen werden, im Moment des Einlösens wird die elektronische Identität mit dem im delegierten Management vorbereiteten Benutzerdatensatz verbunden.
Welche elektronischen Identitäten adäquat sind, ist über die Integration der angesteuerten Zielapplikation definiert. Sind Benutzer, die nicht mit Smartcards der Bundesverwaltung ausgerüstet werden können, das Zielpublikum, bietet das CH-LOGIN die selbstregisrierte, unabgeklärte Variante mit einem oder zwei Loginfaktoren (mTAN und Authenticator App) und eine abgeklärte Variante, letztere mit einem Vasco-Token als zweiten Faktor (siehe CH-LOGIN LOA3).
Für den Einsatz unabgeklärter sowie abgeklärter elektronischer Identitäten im Verkehr mit der Bundesverwaltung wird zukünftig BYOI häufiger, auch im Rahmen des delegierten Managements von eIAM.
Interner Artikel: Delegiertes Management bestellen
Le système eIAM propose la gestion déléguée. Dans dautres systèmes de gestion des identités et des accès (IAM), cette fonctionnalité sappelle attribution déléguée des droits, gestion déléguée des utilisateurs ou encore administration déléguée.
La gestion déléguée na pas lieu dans lapplication admin IDM, mais dans une interface utilisateur web dédiée deIAM. Elle peut également être déclenchée automatiquement par l'application cible au moyen d'une interface (gestion déléguée à distance). Pour pouvoir lutiliser, vous devez demander une seule fois à lOFIT dactiver la gestion déléguée deIAM pour votre mandant daccès eIAM. Pour ce faire, adressez-vous à votre gestionnaire de compte (account manager) de lOFIT.
Pour déléguer la gestion à une ou plusieurs unités organisationnelles internes ou externes, vous devez créer dans eIAM des unités (units) qui les représentent. Les unités constituent ainsi une structuration de votre mandant daccès eIAM. Pour chacune dentre elles, vous invitez au moins un gestionnaire délégué, également dans linterface utilisateur web susmentionnée. Le gestionnaire délégué peut désormais, en toute autonomie, inviter des utilisateurs dans son unité et leur donner des droits. En tant que créateur de lunité, vous déterminez vous-même ses propriétés, les rôles et attributs pouvant être donnés, les applications cibles pouvant être pilotées à partir de cette unité, ou encore si les gestionnaires délégués peuvent eux-mêmes créer des sous-unités et accorder des délégations.
La caractéristique centrale de la gestion déléguée se situe dans les invitations susmentionnées, à savoir linvitation des gestionnaires délégués et linvitation des utilisateurs par ces derniers. La procédure dinvitation offre lavantage de pouvoir créer des utilisateurs et leur accorder des droits, avant même de connaître leur identité électronique. Les utilisateurs reçoivent un code à usage unique (onboarding code), par ex. par courrier électronique, que vous validerez avec une identité électronique adéquate de votre choix. Au moment de la validation, lidentité électronique sera reliée à lenregistrement utilisateur préparé dans la gestion déléguée.
Cest en intégrant lapplication cible que vous définissez quelles identités électroniques sont adéquates. Si des utilisateurs ne pouvant pas disposer de cartes à puce de ladministration fédérale constituent le public cible, le CH-LOGIN propose la variante dautoenregistrement non vérifiée avec un ou deux facteurs de connexion (mTAN et authenticator app) et une variante vérifiée au moyen dun jeton Vasco comme second facteur (voir CH-LOGIN LOA3).
BYOI deviendra plus courant à l'avenir pour l'utilisation d'identités électroniques non vérifiée et vérifiées avec l'administration fédérale, également dans le cadre de la gestion déléguée de eIAM.
Article interne: Delegiertes Management bestellen
eIAM offers delegated management. In other IAM systems, this functionality is described as delegated rights assignment, delegated user management or delegated administration.
Rather than taking place in the IDM admin application, delegated management is in a dedicated web user interface of eIAM. It can also be deployed automatically via an interface by the target application (remote delegated management; RDM). In order to use it, you must ask the FOITT for a one-time release of delegated management for your eIAM access client; please contact your account manager at the FOITT.
In order to delegate to one or more internal or external organisational units, you will need to open units representing these organisational units in eIAM. The units are thus a structure within your eIAM access client. For each unit, and still within the web user interface mentioned above, invite at least one delegated manager. The delegated manager can now independently invite and assign permissions within their unit. As the unit creator, you define the characteristics, the unit, the roles and attributes that can be assigned within it and the target applications that can be run from it, as well as whether the delegated managers can themselves open and delegate units.
The key characteristic of delegated management is the invitations mentioned above, i.e. the ability to invite delegated managers, and in turn their ability to invite users. The invitation process has the advantage of allowing users to be registered and given pre-assigned permissions before their eID is known. Users receive an onboarding code, for example by email, which they can redeem using an appropriate eID of their choosing; at the time of redemption, the eID is linked to the user data set prepared via delegated management.
The appropriateness of an eID is defined by the integration level of the target application. For target audiences comprising users who cannot be equipped with Federal Administration smartcards, CH-LOGIN offers an unauthenticated self-registration option with either one or two-factor authentication (mTAN and authenticator app) and an authenticated option using a Vasco token as the second factor (see CH-LOGIN LOA3).
In the future, BYOI will become more common for the use of unclarified as well as clarified electronic identities in dealings with the federal administration, including in the context of the delegated management of eIAM.
Internal article: Delegiertes Management bestellen
eIAM nutzt als Föderationsverfahren die Identitätsprotokolle OAuth2/OIDC (Open Authorization 2.0/OpenID Connect), SAML2.0 (Security Assertion Markup Language) und WS-Federation. Es können damit Web-Applikationen und native Mobile-Apps* an eIAM angeschlossen werden.
* Beispiel eines eIAM-Logins in einer nativen Mobile-App siehe https://apps.apple.com/ma/app/eiam-… und Quellcode dazu https://github.com/eiam-ch/eiam-ios
Die Identitätsprotokolle legen fest, wie IKT-Systeme untereinander Angaben zu Benutzern, sprich Daten zur Identität und berechtigungsstiftende Daten, austauschen. Die von eIAM verwendeten Identitätsprotokolle sind weltweit verbreitet. Deshalb sind Web-Applikationen und native Mobile-Apps einfach an eIAM anzuschliessen. OTS (off-the-shelf Software) und SaaS (Software as a Service) sind meistens damit bereits ausgerüstet und für Entwicklungsprojekte stehen viele Libraries zur Verfügung. Halten sich Zielsysteme nicht oder nicht vollständig an diese Protokolle, z. B. wenn sie auf proprietären Tokens oder der zusätzlichen Bespielung proprietärer APIs abstellen, werden häufig Authentication Bridges (AB) als Vermittler eingesetzt.
Grâce aux protocoles de fédération didentité Open authorization 2.0/OpenID connect (OAuth2/OIDC), Security assertion markup language 2.0 (SAML2.0) et WS-Federation, les applications web et les applications mobiles natives* peuvent être reliées à eIAM.
* Beispiel eines eIAM-Logins in einer nativen Mobile-App siehe https://apps.apple.com/ma/app/eiam-… und Quellcode dazu https://github.com/eiam-ch/eiam-ios
Ces protocoles déterminent comment les systèmes informatiques échangent des données sur les utilisateurs, plus précisément les données sur les identités et celles qui constituent les autorisations. Ils sont utilisés dans le monde entier, raison pour laquelle les applications web et les applications mobiles natives peuvent facilement être connectées à eIAM. En outre, les logiciels clés en main (off-the-shelf software, OTS) et les logiciels en tant que service (software as a service, SaaS) sont déjà équipés de ces protocoles, et de nombreuses librairies sont disponibles pour les projets de développement. Si des systèmes cibles ne respectent pas ou pas entièrement ces protocoles, par exemple si leurs interfaces de communication reposent sur des jetons propriétaires ou des API propriétaires, des ponts dauthentification (Authentication Bridges (AB)) font souvent office dintermédiaires.
The identity protocols OAuth2/OIDC (open authorisation 2.0/OpenID Connect), SAML2.0 (security assertion markup language) and WS federation are used as identity protocols by eIAM. They allow web applications and native mobile apps* to be connected to eIAM.
* Beispiel eines eIAM-Logins in einer nativen Mobile-App siehe https://apps.apple.com/ma/app/eiam-… und Quellcode dazu https://github.com/eiam-ch/eiam-ios
The identity protocols define how ICT systems exchange user data, i.e. identity data and data required to generate permissions. The identity protocols used by eIAM are commonly used worldwide, which is why web applications and native mobile apps are easy to connect to eIAM. They are generally already integrated into OTS (off-the-shelf software) and SaaS (software as a service), and numerous libraries are available for development projects. If target systems do not comply with these protocols (or not yet fully), for example if they use proprietary tokens or additional proprietary APIs, then Authentication Bridges (ABs) are often used as middleware.
Eine Public-Key-Infrastruktur (PKI) ist ein Set von Rollen, Richtlinien, Hardware, Software und Verfahren, die zur Erstellung, Verwaltung, Verteilung, Verwendung, Speicherung und Widerruf von digitalen Zertifikaten sowie zur Verwaltung der Verschlüsselung mit öffentlichem Schlüssel benötigt werden.
Die PKI des Bundesverwaltung heisst SG-PKI (Swiss Government PKI). Nebst den nachstehend aufgeführten kryptographischen Aufgaben der SG-PKI bildet sie die Grundlage zum Einsatz der elektronischen Identitäten der Mitarbeitenden der Bundesverwaltung und fungiert somit auch als Identitätsprovider.
Der Zweck einer PKI ist es, die sichere elektronische Übertragung von Informationen zu erleichtern. Sie ist für Aktivitäten erforderlich, bei denen einfache Passwörter eine ungeeignete Authentifizierungsmethode darstellen und strengere Beweise zur Bestätigung der Identität der an der Kommunikation beteiligten Parteien und zur Validierung der übertragenen Informationen erforderlich sind.
In der Kryptographie ist eine PKI eine Vorrichtung, die öffentliche Schlüssel mit den jeweiligen Identitäten von Entitäten (wie Personen und Organisationen) verbindet. Die Bindung wird durch einen Prozess der Registrierung und Ausgabe von Zertifikaten bei und durch eine Zertifizierungsstelle (CA) hergestellt. Je nach der Sicherheitsstufe der Bindung kann dies durch einen automatisierten Prozess oder unter menschlicher Aufsicht erfolgen, beim sogenannten Local Registration Authority Officer (LRA).
Une infrastructure à clés publiques (PKI, Public Key Infrastructure) est un ensemble de rôles, de directives, de composants matériels, de logiciels et de procédures nécessaires pour émettre, gérer, distribuer, utiliser, enregistrer et révoquer des certificats numériques ainsi que pour gérer le chiffrement au moyen d'une clé publique.
La PKI de l'administration fédérale est appelée SG PKI (Swiss Government PKI). En sus des opérations de cryptographie de la SG PKI qui sont mentionnées ci-dessous, cette infrastructure constitue la base sur laquelle repose l'utilisation des identités électroniques des collaborateurs de l'administration fédérale et fonctionne dès lors aussi en tant que fournisseur d'identités.
L'objectif d'une PKI est de faciliter la transmission électronique sûre des informations. Cette infrastructure est nécessaire pour effectuer des opérations pour lesquelles les mots de passe simples ne constituent pas une méthode d'authentification appropriée et qui nécessitent de disposer de preuves plus robustes pour attester l'identité des parties qui communiquent et pour valider les informations transmises.
Dans le domaine de la cryptographie, une PKI est une architecture qui lie des clés publiques aux différentes identités des entités (personnes ou organisations). Ce lien est établi via une procédure d'enregistrement auprès d'une autorité de certification (AC) et grâce à lémission de certificats par cette autorité. En fonction du niveau de sécurité du lien, cette procédure peut se faire de manière automatique ou sous la surveillance d'une personne appelée officier LRA (Local Registration Authority).
A public key infrastructure (PKI) is a set of roles, guidelines, hardware, software and procedures that are required for the creation, management, distribution, use, storage and revocation of digital certificates, and for public-key encryption.
The Federal Administration's PKI is called SG PKI (Swiss Government PKI). In addition to the SG PKI's cryptographic functions, it provides the basis for the use of Federal Administration employees' electronic IDs and thus also acts as an identity provider.
The purpose of a PKI is to facilitate the secure electronic transfer of information. It is required for activities where simple passwords are not an appropriate means of authentication and stronger proof is needed to confirm the identity of the communicating parties and to validate the information being transmitted.
In cryptography, a PKI is an arrangement linking public keys with the relevant identities of entities (e.g. people and organisations). The link is created via a process of registration and certificate issuance at and by a certification authority (CA). Depending on the security level, the linkage can take place as an automated process or under human supervision by the Local Registration Authority Officer (LRA).
ONBOARDING
Onboarding bezeichnet den Prozess, welcher notwendig ist, damit ein Benutzer mit einer Zielapplikation arbeiten kann, beschrieben als Leistung 5 im eIAM-Leistungsbeschrieb. Technisch muss folgender Zustand erreicht werden: Der Benutzer hat einen eIAM-Account, ausgerüstet mit Credentials für Loginvorgänge, welcher von der Zielapplikation erkannt und zugelassen wird. Es gibt dabei folgende Ausprägungen der Beziehung der Zielapplikation zu eIAM:
- Ausprägung: Die Benutzerverwaltung wird ausschliesslich in eIAM gemacht. In der Zielapplikation gibt es keine Benutzerdatensätze und keine Datensätze, welche eine Verknüpfung zum technischen Benutzer-Identifikator von eIAM haben. Damit braucht es kein Onboarding des Benutzers in die Zielapplikation. Die Zielapplikation folgt einfach den Aussagen von eIAM zu diesem Benutzer und seinen Berechtigungen (mitgeteilt von eIAM via SAML2.0, OIDC/OAuth2 oder WS-Federation).
Bei dieser Ausprägung kann der Benutzer aus eIAM eingeladen werden die Zielapplikation zu nutzen oder der Benutzer ruft die Zielapplikation ohne Einladung oder Berechtigung auf und beantragt den Zugriff. Erfolgt eine Einladung an den Benutzer, hat der Benutzermanager vorgängig in eIAM die Benutzerberechtigungen erfasst und dem Benutzer einen Einmalcode (eIAM-Onboardingcode) für den erstmaligen Zugriff zugeschickt.
- Ausprägung: Die Benutzerverwaltung wird in eIAM und der Zielapplikation gemeinsam gemacht. Nicht nur in eIAM, sondern auch in der Zielapplikation wird der Benutzer durch einen Datensatz repräsentiert. In diesem Fall muss im Benutzerdatensatz in der Zielapplikation ein technischer Identifikator aus eIAM mitgeführt werden, damit eine Verbindung zwischen dem eIAM-Benutzerdatensatz und dem Applikations-Benutzerdatensatz besteht. Es stellt sich somit die Frage, wie dieser technische Identifikator in den Applikationsdatensatz gelangt. Es gibt dafür folgende Varianten:
- Der Benutzerdatensatz in der Applikation wird beim (erstmaligen) Login des Benutzers angelegt. In dem Moment kennt die Zielapplikation den technischen Identifikator aus eIAM, weil dieser durch eIAM bei jedem Login mitgeteilt wird. Bei dieser Variante kann der Benutzer in der Zielapplikation also nicht im Voraus angelegt werden.
- Der Benutzer wird im Voraus in der Zielapplikation manuell angelegt. Die Zielapplikation generiert einen Einmalcode (Applikations-Onboardingcode) zuhanden des Benutzers.
Beim erstmaligen Zugriff des Benutzers über eIAM auf die Applikation, kann die Applikation den technischen Identifikator aus eIAM nicht zuordnen und präsentiert das Formular zur Eingabe von Applikations-Onboardingcodes. Der Benutzer gibt seinen Applikations-Onboardingcode ein, die Zielapplikation findet damit den Benutzerdatensatz und fügt den technischen Identifikator von eIAM nun ein. - Die Zielapplikation legt den Benutzer und seine Berechtigungen selber in eIAM an, eIAM schickt in der Folge dem Benutzer die Einladung mit Einmalcode (eIAM-Onboardingcode) per E-Mail (sogenanntes Remote-Delegated-Management RDM).
- Die Applikation legt die Benutzer an, in dem sie die Benutzer aus eIAM (eIAM-LDS) ausliest.
Für den vorerwähnten technischen Identifikator aus eIAM kommen vor allem die Datenfelder Subject NameID und Profil ID in Frage. Manchmal wird auch die E-Mailadresse als technischer Identifikator verwendet. Allerdings wird davon abgeraten, da diese leicht veränderlich sind und, vor allem bei Aus- und Eintritten in Firmen, an Namensvettern übergehen können. - Der Benutzerdatensatz in der Applikation wird beim (erstmaligen) Login des Benutzers angelegt. In dem Moment kennt die Zielapplikation den technischen Identifikator aus eIAM, weil dieser durch eIAM bei jedem Login mitgeteilt wird. Bei dieser Variante kann der Benutzer in der Zielapplikation also nicht im Voraus angelegt werden.
ONBOARDING
La notion donboarding définit le processus qui amène un utilisateur à pouvoir utiliser une application cible. Elle est décrite comme Prestation 5 dans la description des prestations eIAM. Du point de vue technique, les conditions suivantes doivent être réunies: lutilisateur possède un compte eIAM avec des identifiants pour les procédures de connexion qui sont reconnus et admis par lapplication cible. La relation entre lapplication cible et eIAM présente les caractéristiques suivantes:
- Caractéristique: La gestion des utilisateurs seffectue exclusivement dans eIAM. Lapplication cible ne contient pas de lots de données relatives aux utilisateurs ni de lots de données qui ont un lien avec lidentifiant technique de lutilisateur deIAM. Lutilisateur ne doit donc pas effectuer donboarding pour pouvoir utiliser lapplication cible. Cette dernière se fonde simplement sur les informations relatives à lutilisateur et ses autorisations contenues dans eIAM (transmises par eIAM via les protocoles didentité SAML2.0, OIDC/OAuth2 ou WS-Federation).
Dans ce cas, eIAM peut inviter lutilisateur à utiliser lapplication cible ou lutilisateur peut appeler lapplication cible sans y être invité ni autorisé et demander laccès. Si une invitation est envoyée à lutilisateur, le gestionnaire des utilisateurs a préalablement saisi les autorisations daccès dans eIAM et a envoyé à lutilisateur un code daccès à usage unique (eIAM-Onboardingcode) pour le premier accès.
- Caractéristique: Ladministration des utilisateurs se fait à la fois dans eIAM et dans lapplication cible. Lutilisateur est représenté par un lot de données, non seulement dans eIAM mais aussi dans lapplication cible.
Dans ce cas, un identifiant technique deIAM doit être inclus dans le lot de données relatives à lutilisateur de lapplication cible afin quune connexion existe entre le lot de données relatives à lutilisateur contenu dans eIAM et le lot de données relatives à lutilisateur de lapplication. Cela soulève la question de savoir comment cet identifiant technique est introduit dans le dossier de données de la demande. Les variantes suivantes existent:- Le lot de données relatives à lutilisateur dans lapplication est créé lorsque lutilisateur se connecte (pour la première fois). À ce moment, lapplication cible connaît lidentifiant technique deIAM, car celui-ci est fourni par eIAM à chaque connexion. Avec cette variante, lutilisateur ne peut donc pas être créé à lavance dans lapplication cible.
- Lutilisateur est créé manuellement à lavance dans lapplication cible. Lapplication cible génère un code daccès à usage unique (onboardingcode de lapplication) pour lutilisateur.
Lorsque lutilisateur accède pour la première fois à lapplication via eIAM, lapplication ne peut pas attribuer lidentifiant technique deIAM et présente le formulaire de saisie des codes daccès de lapplication. Lutilisateur entre son code daccès, lapplication cible trouve le lot de données relatives à lutilisateur et insère lidentifiant technique deIAM - L'application cible configure elle-même l'utilisateur et les autorisations qu'il détient dans eIAM, qui envoie ensuite à l'utilisateur l'invitation avec un code à usage unique (eIAM onboarding code) par courrier électronique (gestion déléguée à distance).
- Lapplication crée les profils dutilisateurs en sélectionnant ceux deIAM (eIAM-LDS).
Pour lidentifiant technique susmentionné deIAM, les champs de données Subject NameID et Profil ID sont particulièrement adaptés. Parfois, ladresse électronique est également utilisée comme identifiant technique, mais cela nest pas recommandé, car elle est facilement modifiable et peut être transmise à des homonymes, notamment en cas de sortie ou dentrée dans une entreprise. - Le lot de données relatives à lutilisateur dans lapplication est créé lorsque lutilisateur se connecte (pour la première fois). À ce moment, lapplication cible connaît lidentifiant technique deIAM, car celui-ci est fourni par eIAM à chaque connexion. Avec cette variante, lutilisateur ne peut donc pas être créé à lavance dans lapplication cible.
ONBOARDING
Onboarding is the process that is needed in order that the user can work with a target application; see Service 5 in "Description of eIAM service". In technical terms, the following state must be achieved: The user has an eIAM account that is equipped with credentials for login procedures, and is recognised and authorised by the target application. The following types of relationship between the target application and eIAM are possible:
- Type: User management is performed exclusively in eIAM. The target application contains no user data sets or other data sets linked to eIAM's technical user identifier. Onboarding of the user in the target application is not necessary; the target application simply acts on the statements made by eIAM concerning that user and the associated authorisations (provided by eIAM via SAML2.0, OIDC/OAuth2 oder WS-Federation).
In this relationship type, the user from eIAM can be invited to use the target application, or the user can call up the target application without an invitation or authorisation and request access. If the user is invited, the user manager has recorded the user authorisations in eIAM beforehand, and sent the user a one-time code (eIAM onboarding code) to use when accessing the application for the first time.
- Type:
User management is performed jointly in eIAM and the target application. The user is represented by a data set in both eIAM and the target application. In this case, the user data set in the target application must contain a technical identifier from eIAM, in order to create a link between eIAM's user data set and the application's user data set. So how is this technical identifier incorporated into the application data set? There are the following options:- The user data set in the application is set up when the user logs in (for the first time). At that moment, the target application recognises the technical identifier from eIAM, because the identifier is provided by eIAM at every login. With this option, the user cannot be entered in the target application in advance.
- The user is set up manually in the target application in advance. The target application generates a one-time code (application onboarding code) for the user.
When the user accesses the application via eIAM for the first time, the application cannot recognise the technical identifier from eIAM and presents the form for entering application onboarding codes. The user enters the application onboarding code; the target application can then locate the user data set and enter the technical identifier from eIAM. - The target application itself sets up the user and the associated permissions in eIAM. eIAM then sends the user the invitation with a single-use code (eIAM onboarding code) by email (so-called remote delegated management; RDM).
- The application sets up the user by selecting the user from eIAM (eIAM-LDS).
The key data fields for the eIAM technical identifier mentioned above are: Subject NameID and Profil ID. Sometimes, email addresses are also used as technical identifiers; however this is not advisable because these addresses can be easily changed and, particularly when people join or leave a company, can be transferred to namesakes. - The user data set in the application is set up when the user logs in (for the first time). At that moment, the target application recognises the technical identifier from eIAM, because the identifier is provided by eIAM at every login. With this option, the user cannot be entered in the target application in advance.
PAMS ist ein Accessmanagementsystem, welches von der Digitalisierungsplattform DIP für die ESTV entwickelt wurde. PAMS bezieht die Identitäten von eIAM, managt die Rechtevergabe und das delegierte Management aber selbständig. PAMS ist ein Microservice in einer von der DIP orchestrierten Microservices-Landschaft, welche in Absprache mit der DIP genutzt werden kann, wenn Entwicklungsprojekte auf die APIs dieser Landschaft hin entwickelt werden.
Bei eIAM werden Applikationen nicht gegen eIAM-APIs entwickelt, sondern mittels der «Protokolle» SAML, OIDC, OIDC OAuth2, WS-Fed an eIAM angeschlossen. Die Accessmanagements von eIAM und PAMS sind ähnlich. Das Accessmanagement von eIAM kann übersprungen werden, wenn die Rechtevergabe in der Zielapplikation erfolgen soll (reiner Identitätsbezug bei eIAM, sog. Autoenrolment im Silentmode).
Die Wahl direkter eIAM-Anschluss oder eIAM-Nutzung via PAMS wird durch die Art des Vorhabens bestimmt: Eingekaufte Applikationen sind für den Anschluss an eIAM geeignet, (interne) Entwicklungsprojekte können gegen die PAMS APIs gemacht werden, wie dies aktuell für das Transaktionsportal EFD namens ePortal (inkl. DaziT) gemacht wird. Bei der Wahl PAMS oder eIAM bei (internen) Entwicklungsprojekten kann ausschlaggebend sein, ob generell Leistungen aus der Microservices-Landschaft der DIP bezogen werden sollen und ob die API-Ausprägung der Accessmanagementlösung PAMS ein wichtiges Kriterium ist.
Soll eine neue Applikation PAMS als Accessmanagement nutzen, wird eine Applikation gegen die PAMS-API entwickelt und durchläuft keine eIAM-Integration, weil PAMS bereits nach eIAM integriert ist. Soll eine neue Applikation eine App im ePortal (www.eportal.admin.ch) sein, durchläuft die Applikation keine eIAM-Integration, weil Applikationen im ePortal immer die PAMS-API nutzen und PAMS bereits nach eIAM integriert ist.
PAMS bleibt für die Applikationsnutzenden unsichtbar. Das Benutzererlebnis besteht aus den Schritten Applikation aufrufen, über eIAM einloggen, Applikation nutzen. Siehe Beispiel www.eiam.admin.ch/eg.
Unabhängig davon, ob eine Applikation mit dem Accessmanagement von PAMS oder dem Accessmanagement von eIAM operiert, die verwendeten elektronischen Identitäten und somit auch die dazugehörigen Credentials (z. B. Passwort) sind dieselben, da immer zentral von eIAM vermittelt, dies gilt auch für externe Identitätslieferanten wie z. B. SwissID, TrustID und ggf. Social-IdPs von Google, Facebook etc.
PAMS est un système de gestion des accès développé par la plateforme sur la numérisation pour lAdministration fédérale des contributions (AFC). PAMS reçoit les identités deIAM, mais gère lattribution des droits et la gestion déléguée de manière autonome. PAMS est un microservice dans un environnement de microservices géré par la plateforme sur la numérisation qui peut être utilisé en accord avec cette dernière, si les projets peuvent être développés sur les interfaces de programmation dapplication (application programming interface, API) de cet environnement.
Avec eIAM, les applications ne sont pas développées sur les API deIAM, mais reliées à eIAM au moyen des protocoles SAML, OIDC, OIDC OAuth2. La gestion des accès deIAM et celle de PAMS sont semblables. La gestion des accès deIAM peut être sautée si lattribution des droits doit se faire dans lapplication cible (simple obtention des identités dans eIAM, dénommée autoenrolment en mode silencieux).
Le choix dune connexion directe à eIAM ou dune utilisation deIAM via le microservice PAMS est déterminé par le genre de projet: les applications achetées se prêtent à une connexion à eIAM, les projets de développement (internes) peuvent être réalisés sur les API de PAMS, comme cest le cas actuellement pour le portail administratif du DFF «ePortal» (y c. le programme DaziT). Pour choisir PAMS ou eIAM dans le cas de projets de développement (internes), il peut savérer déterminant de savoir si de manière générale des prestations devront être obtenues à partir de lenvironnement de microservices de la plateforme sur la numérisation et si la présence de lAPI de la solution de gestion des accès de PAMS est un critère important.
Les nouvelles applications qui utilisent PAMS comme système de gestion des accès et sont développées sur linterface de programmation (application programming interface, API) de PAMS ne doivent pas être raccordées au service eIAM. En effet, elles obtiennent automatiquement les identités électroniques via eIAM étant donné que PAMS est déjà relié à ce service. Les nouvelles applications mises en service sur le portail en ligne (www.eportal.admin.ch) ne doivent pas être intégrées à eIAM, car les applications disponibles sur ce portail utilisent toujours lAPI de PAMS.
PAMS nest pas visible pour les utilisateurs. Pour se servir dune application, ces derniers ont uniquement besoin de la démarrer puis de se connecter à eIAM. Un exemple concret est disponible sous www.eiam.admin.ch/eg.
Que lapplication opère avec la gestion des accès de PAMS ou celle deIAM, les identités électroniques utilisées et les identifiants correspondants (par ex. mots de passe) sont les mêmes, puisque ceux-ci sont fournis de manière centralisée par eIAM. Cela vaut aussi pour les fournisseurs externes didentités, tels que SwissID ou TrustID.
PAMS is an access management system developed by the DIP digitalisation platform for the FTA. PAMS obtains the identities from eIAM, but manages permissions assignment and delegated management autonomously. PAMS is a microservice in a microservices landscape orchestrated by the DIP, and can be used in consultation with the DIP if development projects are run on the APIs of this landscape.
In eIAM, applications are not developed for eIAM APIs, but are connected to eIAM using the SAML, OIDC or OAuth2 protocols. The access managements of eIAM and PAMS are similar. The eIAM access management can be bypassed if permissions are to be assigned in the target application (only the ID is obtained in eIAM = autoenrolment in silent mode).
The choice of directly connecting to eIAM or using eIAM via PAMS is dictated by the project type: purchased applications are suitable for direct connection to eIAM, whereas (internal) development projects can be performed with the PAMS APIs, as is currently the case with the FDF transaction portal «ePortal» (including DaziT). When deciding whether to use PAMS or eIAM for (internal) development projects, a key factor is whether services are to be obtained from the DIP microservices landscape and whether the API design of the PAMS access management solution is an important criterion.
If a new application is intended to use PAMS for access management, an application is developed with the PAMS API and does not undergo eIAM integration, because PAMS is already integrated according to eIAM. If a new application is also to appear in ePortal (www.eportal.admin.ch), it does not undergo eIAM integration, because ePortal applications always use the PAMS API and PAMS is already integrated according to eIAM.
PAMS remains invisible for the application users. The user experience consists of calling up the application, logging in via eIAM and using the application. See the example at www.eiam.admin.ch/eg.
Irrespective of whether an application is run with the PAMS access management or that of eIAM, the eIDs employed, and thus the associated credentials (e.g. password) are the same, because they are always provided centrally by eIAM. This also applies to external IdPs such as SwissID or TrustID.
Die Zielapplikation erhält die Angaben zum Benutzer im Moment des Logins, eIAM übermittelt in dem Moment ein Datenset gemäss SAML, OIDC oder WS-Federation.
Falls Applikationen ausserhalb des Login-Zeitpunkts Informationen über Benutzer benötigen, ist folgendes möglich:
eIAM-LDS: Diese Servicekomponente bietet eine LDAP Schnittstelle, auf welcher die Anwendung mittels eines technischen Users Attribute und Rolleninformationen des Benutzers abrufen kann. Der Zugriff auf diese Schnittstelle erfolgt von der Anwendung nur lesend und nur innerhalb der Netze der Bundesverwaltung.
eIAM-WS: Diese Servicekomponente bietet eine SOAP Web Service Schnittstelle, auf welcher die Anwendung mittels eines technischen Users Attribute und Rolleninformationen aus dem eigenen eIAM-Access-Mandanten abfragen und auch updaten kann. Der Zugriff auf diese Schnittstelle erfolgt von der Anwendung lesend und schreibend von innerhalb und ausserhalb der Netzwerke der Bundesverwaltung.
CIS-DBP*: Beim Datenbezugspunkt des Central Identity Stores CIS können identitätsstiftende Daten von Mitarbeitenden der Bundesverwaltung und Affiliierter im Enterprise-Kontext abgefragt werden.
CIS-DVP*: Datenverteilpunkt. Wie CIS-DBP, aber proaktiv provisionierend in Richtung Zielapplikationen.
*CIS-DBP und CIS-DVP sind Leistungen des CIS und nicht von eIAM, sie werden hier aber aufgeführt, da häufig im Zusammenhang mit eIAM verwendet.
L'application cible reçoit les informations sur l'utilisateur lors de la connexion, car eIAM transmet à ce moment-là un jeu de données selon le standard SAML, OpenID Connect ou WS-Federation.
Si des applications requièrent des informations sur un utilisateur en dehors du moment où ce dernier se connecte, les possibilités sont les suivantes :
eIAM-LDS: ce composant service fournit une interface LDAP sur laquelle l'application peut consulter les attributs et les informations sur les rôles de lutilisateur au moyen d'un utilisateur technique. L'application a accès à cette interface en mode lecture uniquement et seulement au sein des réseaux de l'administration fédérale.
eIAM-WS: ce composant service fournit une interface web service SOAP, sur laquelle l'application peut, au moyen d'un utilisateur technique, consulter les attributs et les informations sur les rôles dans son propre mandant daccès eIAM et également mettre à jour ces données. L'application a accès à cette interface en mode lecture et écriture tant au sein des réseaux de l'administration fédérale qu'en dehors de ceux-ci.
Point de référence des données CIS (CIS-PRD*): le point de référence des données (Datenbezugspunkt) CIS (Central Identity Store) permet de consulter les données qui constituent les identités des collaborateurs de l'administration fédérale et des personnes affiliées dans le contexte d'une entreprise.
Point de distribution des données CIS (CIS-PDD*): similaire au CIS-PRD, le point de distribution des données CIS est responsable du provisioning, soit la création automatique didentités et de rôles dutilisateurs pour le compte des applications cibles.
*Le CIS-PRD et le CIS-PDD sont des prestations du central identity store (CIS) et non deIAM, mais ils sont définis ici car ils sont souvent utilisés en corrélation avec eIAM.
The target application receives the information on the user at the time of login; at that time, eIAM transmits a data set according to SAML, OIDC or WS federation.
If applications require user information outside the time of login, the following possibilities exist:
eIAM LDS: This service component offers an LDAP interface on which the application can retrieve user attributes and role information by means of a technical user. Access to this interface is read-only and solely within Federal Administration networks.
eIAM WS: This service component offers a SOAP web service interface on which the application can search for and update attributes and role information from its own eIAM access client by means of a technical user. Access to this interface is read-and-write and outside Federal Administration networks.
CIS DRP*: The data retrieval point of the central identity store (CIS) can be used to search for identity-establishing data of Federal Administration employees and affiliates in the enterprise context.
CIS DDP*: data distribution point. Like CIS DRP, but with proactive provisioning towards the target application.
*CIS DRP and CIS DDP are services provided by the CIS rather than eIAM, but they are listed here since they are often used in relation to eIAM.
Die Schutzstufen haben einen Einfluss auf die minimal notwendige Authentisierungsstärke/ -qualität, in eIAM wird diese als Quality of Authentication (QoA) bezeichnet und mit zweistelligen Zahlen bewertet, siehe dazu auch www.eiam.admin.ch/qoa
Hinweis: Häufige Missverständnisse bezüglich VERTRAULICH
Die einer Applikation/Datensammlung zuzuweisende Schutzstufe ist das Ergebnis der obligatorischen Schutzbedarfsanalyse (https://www.ncsc.admin.ch/ncsc/de/h…).
Die Schutzstufe erfasst die Anforderungen aus dem Datenschutzgesetz (DSG, https://www.fedlex.admin.ch/eli/oc/…) und der Verordnung über den Schutz von Informationen des Bundes (ISV, https://www.fedlex.admin.ch/eli/cc/…). Die Bezeichnung der Schutzstufe besteht also aus einer einstelligen Zahl (0 bis 3) und einem einzelnen Grossbuchstaben (A bis D).
Anforderungen DSG, Zahl der Schutzstufe
- 0 = keine Personendaten* involviert.
- 1 = Personendaten involviert, aber nicht besonders schützenswerte und keine Profilbildungsgefahr.
- 2 = Personendaten involviert, die besonders schützenswert** sind oder zu einer Profilbildung führen können.
- 3 = Personendaten involviert, deren Missbrauch für den Betroffenen Gefahren für Leib & Leben bedeuten.
*Personendaten (DSG Kpt.2, Absatz 1,Art. 5, Buchstabe a): alle Angaben, die sich auf eine bestimmte oder bestimmbare natürliche Person beziehen**besonders schützenswerte Personendaten (DSG Kpt.2, Absatz 1,Art. 5, Buchstabe c): 1. Daten über religiöse, weltanschauliche, politische oder gewerkschaftliche Ansichten oder Tätigkeiten, 2. Daten über die Gesundheit, die Intimsphäre oder die Zugehörigkeit zu einer Rasse oder Ethnie, 3. genetische Daten, 4. biometrische Daten, die eine natürliche Person eindeutig identifizieren, 5. Daten über verwaltungs- und strafrechtliche Verfolgungen oder Sanktionen und 6.Daten über Massnahmen der sozialen Hilfe.
- A = nicht klassifiziert
- B = INTERN
- C = VERTRAULICH
- D = GEHEIM
*Gemäss Klassifizierungsstufen in der ISV Verordnung
Bedeutung für die IAM-Leistungen
- 0A = QoA 30*, Datenhaltung in public Clouds erlaubt, Unterliegt dem sog. Grundschutz.
- 0B = QoA 40, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Grundschutz.
- 0C = QoA 50**, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Erhöhten Schutz.
- 0D = keine übliche Digitalisierung mit vorgeschaltetem IAM möglich. Unterliegt dem sog. Erhöhten Schutz.* Alias «Zwei-Faktor-Authentifizierung» ist bei Logins «Best Practice». QoA10 und QoA20 sollen nicht mehr erfasst werden.
** Die Authentisierung auf QoA50 allein reicht nicht für VERTRAULICH aus, es müssen ausserhalb von IAM Massnahmen getroffen werden wie die Verwendung vertrauenswürdiger Hardware, Datenverschlüsselung etc. - 1A = QoA 30, Datenhaltung in public Clouds erlaubt, Unterliegt dem sog. Grundschutz.
- 1B = QoA 40, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Grundschutz.
- 1C = QoA 50**, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Erhöhten Schutz.
- 1D = keine übliche Digitalisierung mit vorgeschaltetem IAM möglich. Unterliegt dem sog. Erhöhten Schutz.** Die Authentisierung auf QoA50 allein reicht nicht für VERTRAULICH aus, es müssen ausserhalb von IAM Massnahmen getroffen werden wie die Verwendung vertrauenswürdiger Hardware, Datenverschlüsselung etc.
- 2A = QoA 50, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Erhöhten Schutz.
- 2B = QoA 50, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Erhöhten Schutz.
- 2C = QoA 50**, Datenhaltung in public Clouds NICHT erlaubt, Unterliegtdem sog. Erhöhten Schutz.
- 2D = keine übliche Digitalisierung mit vorgeschaltetem IAM möglich. Unterliegt dem sog. Erhöhten Schutz.** Die Authentisierung auf QoA50 allein reicht nicht für VERTRAULICH aus, es müssen ausserhalb von IAM Massnahmen getroffen werden wie die Verwendung vertrauenswürdiger Hardware, Datenverschlüsselung etc.
- 3A = QoA 50***, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Erhöhten Schutz.
- 3B = QoA 50***, Datenhaltung in public Clouds NICHT erlaubt, Unterliegt dem sog. Erhöhten Schutz.
- 3C = QoA 50***, Datenhaltung in public Clouds NICHT erlaubt, Unterliegtdem sog. Erhöhten Schutz.
- 3D = keine übliche Digitalisierung mit vorgeschaltetem IAM möglich. Unterliegt dem sog. Erhöhten Schutz.
*** Zusatzmassnahmen ähnlich ** notwendig, vgl. SSO-Portal EJPD
-
- Click on the image to enlarge
Elektronische Bearbeitungsvorschriften für Daten mit sog. Erhöhten Schutz:
Bei den Klassifizierungsstufen GEHEIM und VERTRAULICH müssen die Daten auf Arbeitsplatzsystemen und entfernbaren Datenträger wie auch beim elektronischen Versand und Empfang, dem Stand der Technik entsprechend, verschlüsselt werden.
Les niveaux de protection ont une influence sur la force dauthentification (ou qualité dauthentification) minimale requise. Cette caractéristique, appelée Quality of Authentication (QoA) dans eIAM, se traduit par un score à deux caractères (cf. https://www.eiam.admin.ch/qoa).
Hinweis: Häufige Missverständnisse bezüglich VERTRAULICH
Le niveau de protection à conférer à une application ou à une base de données est défini en fonction des résultats de lanalyse obligatoire des besoins de protection (cf. https://www.ncsc.admin.ch/ncsc/fr/h…).
Le niveau de protection tient compte des exigences posées par la loi fédérale sur la protection des données (LPD, https://www.fedlex.admin.ch/eli/oc/…) et lordonnance concernant la protection des informations (OSI, https://www.fedlex.admin.ch/eli/cc/…). Le niveau de protection correspond à un code composé de deux caractères : un chiffre allant de 0 à 3 et une lettre allant de A à D.
Exigences de la LPD, chiffre déterminant le niveau de protection
- 0 = Aucune donnée personnelle*
- 1 = Données personnelles non sensibles, aucun risque quun tiers puisse établir un profil
- 2 = Données personnelles sensibles** ou données personnelles qui peuvent permettre à un tiers détablir un profil
- 3 = Données personnelles dont lutilisation abusive peut mettre en danger la vie et lintégrité corporelle de la personne concernée
*Données personnelles (chap. 2, section 1, art. 5, let. a, LPD ) : toutes les informations concernant une personne physique identifiée ou identifiable**Données personnelles sensibles (chap. 2, section 1, art. 5, let. c, LPD) : 1 les données sur les opinions ou les activités religieuses, philosophiques, politiques ou syndicales, 2 les données sur la santé, la sphère intime ou lorigine raciale ou ethnique, 3 les données génétiques, 4 les données biométriques identifiant une personne physique de manière univoque, 5les données sur des poursuites ou sanctions pénales et administratives et 6 les données sur des mesures daide sociale.
- A = non classifié
- B = INTERNE
- C = CONFIDENTIEL
- D = SECRET
*Échelons de classification tels que décrits dans OSI
Comment ces bases légales se traduisent-elles dans eIAM ?
- 0A = QoA 30*, conservation des données sur des nuages publics autorisée, protection de base applicable
- 0B = QoA 40, conservation des données sur des nuages publics INTERDITE, protection de base applicable
- 0C = QoA 50**, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 0D = Digitalisation classique au moyen dun système IAM connecté exclue, protection renforcée applicable* Lauthentification à deux facteurs figure parmi les bonnes pratiques de connexion. De ce fait, les niveaux QoA 10 et QoA 20 sont caducs.
** Le niveau QoA 50 nest pas suffisant pour les documents classifiés « CONFIDENTIEL » : des mesures de sécurité supplémentaires doivent donc être mises en place en parallèle dIAM (notamment lutilisation de matériel informatique sécurisé, le chiffrement des données, etc.). - 1A = QoA 30, conservation des données sur des nuages publics autorisée, protection de base applicable
- 1B = QoA 40, conservation des données sur des nuages publics INTERDITE, protection de base applicable
- 1C = QoA 50**, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 1D = Digitalisation classique au moyen dun système IAM connecté exclue, protection renforcée applicable** Le niveau QoA 50 nest pas suffisant pour les documents classifiés « CONFIDENTIEL » : des mesures de sécurité supplémentaires doivent donc être mises en place en parallèle dIAM (notamment lutilisation de matériel informatique sécurisé, le chiffrement des données, etc.).
- 2A = QoA 50, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 2B = QoA 50, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 2C = QoA 50**, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 2D = Digitalisation classique au moyen dun système IAM connecté exclue, protection renforcée applicable** Le niveau QoA 50 nest pas suffisant pour les documents classifiés « CONFIDENTIEL » : des mesures de sécurité supplémentaires doivent donc être mises en place en parallèle dIAM (notamment lutilisation de matériel informatique sécurisé, le chiffrement des données, etc.).
- 3A = QoA 50***, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 3B = QoA 50***, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 3C = QoA 50***, conservation des données sur des nuages publics INTERDITE, protection renforcée applicable
- 3D = Digitalisation classique au moyen dun système IAM connecté exclue, protection renforcée applicable
*** Mesures supplémentaires similaires ** caractère contraignant, cf. portail SSO DFJP
-
- Click on the image to enlarge
Prescriptions relatives au traitement électronique des données nécessitant une protection renforcée : les données des documents classifiés « CONFIDENTIEL » et « SECRET » doivent être chiffrées (conformément à létat de la technique) sur les systèmes de poste de travail et les supports de données amovibles et également lors de lenvoi et la réception des documents concernés.
I livelli di protezione influiscono sulla qualità / sulla robustezza minima necessaria per lautenticazione. Su eIAM questultima è denominata «quality of authentication» (QoA) ed è valutata con numeri a due cifre (cfr. www.eiam.admin.ch/qoa).
Hinweis: Häufige Missverständnisse bezüglich VERTRAULICH
Il livello di protezione attribuito a unapplicazione / a una raccolta di dati è determinato dallanalisi obbligatoria dei requisiti di protezione (https://www.ncsc.admin.ch/ncsc/de/h…).
Il livello di protezione soddisfa i requisiti stabiliti nella legge federale del 25 settembre 2020 sulla protezione dei dati (LPD; RS 235.1 https://www.fedlex.admin.ch/eli/oc/…) e nellordinanza del 4 luglio 2007 sulla protezione delle informazioni (OSIn; https://www.fedlex.admin.ch/eli/cc/…). La denominazione del livello di protezione consiste di una cifra (da 0 a 3) e di una lettera maiuscola (dalla A alla D).
Requisiti stabiliti nella LPD (livelli di protezione)
- 0 = non viene menzionato alcun dato personale*
- 1 = vengono menzionati dati personali non degni di particolare protezione e che non comportano alcun rischio di profilazione
- 2 = vengono menzionati dati personali particolarmente degni di protezione** e che comportano un rischio di profilazione
- 3 = vengono menzionati dati personali la cui violazione comporta un pericolo per la vita e lintegrità delle persone interessate
*Dati personali (art. 5 lett. a LPD): tutte le informazioni concernenti una persona fisica identificata o identificabile**Dati personali degni di particolare protezione (art. 5 lett. c LPD): 1. i dati concernenti le opinioni o attività religiose, filosofiche, politiche o sindacali, 2. i dati concernenti la salute, la sfera intima o lappartenenza a una razza o a unetnia, 3. i dati genetici, 4. i dati biometrici che identificano in modo univoco una persona fisica, 5. i dati concernenti perseguimenti e sanzioni amministrativi e penali e 6. i dati concernenti le misure dassistenza sociale.
- A = NON CLASSIFICATO
- B = AD USO INTERNO
- C = CONFIDENZIALE
- D = SEGRETO
*I livelli di classificazione sono OSIn.
- 0A = QoA 30*: larchiviazione dei dati in cloud pubblici è permessa ed è soggetta alla protezione di base
- 0B = QoA 40: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione di base
- 0C = QoA 50**: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 0D = la digitalizzazione standard con IAM preinstallato non è possibile ed è soggetta alla protezione elevata* Ciò significa che lautenticazione a due fattori è considerata una buona pratica per i login; QoA 10 e QoA 20 non devono più essere registrate.
** La mera autenticazione QoA 50 non è sufficiente per il livello di classificazione CONFIDENZIALE. Devono pertanto essere adottate misure al di fuori di IAM, quali lutilizzo di hardware affidabili, la crittografia dei dati ecc. - 1A = QoA 30: larchiviazione dei dati in cloud pubblici è permessa ed è soggetta alla protezione di base
- 1B = QoA 40: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione di base
- 1C = QoA 50**: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 1D = la digitalizzazione standard con IAM preinstallato non è possibile ed è soggetta alla protezione elevata** La mera autenticazione QoA 50 non è sufficiente per il livello di classificazione CONFIDENZIALE. Devono pertanto essere adottate misure al di fuori di IAM, quali lutilizzo di hardware affidabili, la crittografia dei dati ecc.
- 2A = QoA 50: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 2B = QoA 50: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 2C = QoA 50**: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 2D = la digitalizzazione standard con IAM preinstallato non è possibile ed soggetta alla protezione elevata** La mera autenticazione QoA 50 non è sufficiente per il livello di classificazione CONFIDENZIALE. Devono pertanto essere adottate misure al di fuori di IAM, quali lutilizzo di hardware affidabili, la crittografia dei dati ecc.
- 3A = QoA 50***: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 3B = QoA 50***: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 3C = QoA 50***: larchiviazione dei dati in cloud pubblici NON è permessa ed è soggetta alla protezione elevata
- 3D = la digitalizzazione standard con IAM preinstallato non è possibile ed è soggetta alla protezione elevata
*** Sono necessarie misure aggiuntive simili a **, cfr. il portale SSO del DFGP.
-
- Click on the image to enlarge
Prescrizioni elettroniche concernenti il trattamento dei dati soggetti alla protezione elevata:
per i livelli di classificazione SEGRETO e CONFIDENZIALE, i dati registrati sulle postazioni di lavoro o sui supporti di dati removibili, come pure al momento dellinvio e della ricezione per via elettronica degli stessi, devono essere crittografati conformemente allo stato della tecnica.
The protection levels impact the minimum required authentication strength/quality; this is referred to as quality of authentication (QoA) in eIAM and is rated with two-digit numbers, see also www.eiam.admin.ch/qoa.
Hinweis: Häufige Missverständnisse bezüglich VERTRAULICH
The protection level assigned to an application/data collection is determined by the mandatory protection needs analysis (https://www.ncsc.admin.ch/ncsc/de/h…).
The protection level covers the requirements of the Data Protection Act (FADP, https://www.fedlex.admin.ch/eli/oc/…) and of the Information Protection Ordinance (ISV, https://www.fedlex.admin.ch/eli/cc/…). The designation of the protection level consists of one digit (0 to 2) and a capital letter (A to D).
FADP requirements, protection level digit
- 0 = no personal data* involved
- 1 = involvement of personal data that is not sensitive and there is no risk of profiling
- 2 = involvement of personal data that is sensitive** or may lead to profiling
- 3 = involvement of personal data which, if misused, could represent a danger to life and limb for the person concerned
*Personal data (FADP chapter 2 section 1 Article 5 letter a): any information relating to an identified or identifiable natural person**Sensitive personal data (FADP chapter 2 section 1 Article 5 letter c): 1. data relating to religious, philosophical, political or trade union-related views or activities, 2. data relating to health, the private sphere or affiliation to a race or ethnicity, 3. genetic data, 4. biometric data that uniquely identifies a natural person, 5. data relating to administrative and criminal proceedings or sanctions and 6. data relating to social assistance measures
- A = unclassified
- B = INTERNAL
- C = CONFIDENTIAL
- D = SECRET
*According the Classification levels in the ISV.
- 0A = QoA 30*, data storage in public clouds permitted, subject to basic protection.
- 0B = QoA 40, data storage in public clouds NOT permitted, subject to basic protection.
- 0C = QoA 50**, data storage in public clouds NOT permitted, subject to enhanced protection.
- 0D = standard digitalisation with upstream IAM not possible, subject to enhanced protection.* Two-factor authentication is considered best practice for logins. QoA10 and QoA20 should no longer be used.
** QoA50 authentication alone is not sufficient for CONFIDENTIAL; measures must be taken outside IAM, such as the use of trusted hardware, data encryption, etc. - 1A = QoA 30, data storage in public clouds permitted, subject to basic protection.
- 1B = QoA 40, data storage in public clouds NOT permitted, subject to basic protection.
- 1C = QoA 50**, data storage in public clouds NOT permitted, subject to enhanced protection.
- 1D = standard digitalisation with upstream IAM not possible, subject to enhanced protection.** QoA50 authentication alone is not sufficient for CONFIDENTIAL; measures must be taken outside IAM, such as the use of trusted hardware, data encryption, etc.
- 2A = QoA 50, data storage in public clouds NOT permitted, subject to enhanced protection.
- 2B = QoA 50, data storage in public clouds NOT permitted, subject to enhanced protection.
- 2C = QoA 50**, data storage in public clouds NOT permitted, subject to enhanced protection.
- 2D = standard digitalisation with upstream IAM not possible, subject to enhanced protection.** QoA50 authentication alone is not sufficient for CONFIDENTIAL; measures must be taken outside IAM, such as the use of trusted hardware, data encryption, etc.
- 3A = QoA 50***, data storage in public clouds NOT permitted, subject to enhanced protection.
- 3B = QoA 50***, data storage in public clouds NOT permitted, subject to enhanced protection.
- 3C = QoA 50***, data storage in public clouds NOT permitted, subject to enhanced protection.
- 3D = standard digitalisation with upstream IAM not possible, subject to enhanced protection.*** Additional measures similar to ** necessary; see FDJP SSO portal
-
- Click on the image to enlarge
Electronic processing regulations for data with enhanced protection:
For the classification levels SECRET and CONFIDENTIAL, the data on workstation systems and removable data carriers must be encrypted in accordance with the state of the art. The same applies during the electronic transmission and receipt of such data.
Identitäts- und Accessmanagement Systeme (IAM-Systeme) wie eIAM erfüllen die Aufgaben der (Wieder-)Erkennung von Benutzern (Identität) und optional der Übermittlung von Aussagen zu deren Berechtigungen in den Zielapplikationen (Access).
Das elektronische Signieren ist nicht Bestandteil der Leistung eines IAM-Systems. eIAM bietet keine digitalen Signaturen an. Die Leistung von IAM-Systemen, vereinfacht gesagt der darüber geführte Anmeldevorgang, kann aber grundsätzlich zum Auslösen einer elektronischen Signatur über einen an der Zielapplikation angeschlossenen Signaturservice genutzt werden.
Mitarbeitende der Bundesverwaltung können mit den Mitteln der SG-PKI elektronisch signieren. Soll der Signaturvorgang basierend auf der SG-PKI in einer Bundes-Applikation implementiert sein, muss dafür zwingend der Standarddienst «Signaturdienste» der Bundesverwaltung verwendet werden.
Für automatische (Massen-)Signaturen ist in der Bundesverwaltung mehrheitlich das unpersönliche Behördensiegel vorgesehen. Die Signaturdienste der Bundesverwaltung können gemäss Finanzhaushaltgesetz den Verwaltungsebenen ausserhalb der Bundesverwaltung nur im vorerwähnten Rahmen zugänglich gemacht werden. Hierzu sind eine Bundes-Applikationen mit dem Bund als Eigner, eine Smartcard der SG-PKI und ein Bundesarbeitsplatz Voraussetzung. Öffentlich erhältlich ist die Validator-Applikation www.validator.ch, mit welcher elektronische Signaturen gemäss ZertES überprüft werden können.
Weitere Informationen zu digitalen Signaturen für Bürgerinnen und Bürger sind auf der Seite https://www.openegov.admin.ch/egov/… erhältlich.
Les systèmes de gestion des identités et des accès (identity and access management, IAM) tels queIAM ont pour rôle didentifier (une ou plusieurs fois) les utilisateurs et, le cas échéant, de transmettre des informations sur les autorisations aux applications cibles.
Les signatures électroniques ne sont pas comprises dans les prestations des systèmes IAM. eIAM noffre donc pas cette possibilité à ses utilisateurs. En revanche, il est en principe possible dutiliser la prestation des systèmes IAM, autrement dit la procédure de connexion réalisée par leur intermédiaire, pour déclencher le processus de signature électronique dun service ad hoc raccordé à une application cible.
Les collaboratrices et collaborateurs de ladministration fédérale peuvent signer leurs documents de manière électronique grâce à la procédure de la Swiss Government PKI (SG PKI).
Si cette dernière doit être implémentée dans une application de la Confédération, le service de signature standardisé de l'administration fédérale doit être impérativement utilisé.
En ce qui concerne les signatures automatiques de masse, il convient généralement dutiliser le cachet officiel électronique ou «sceau de lautorité». Conformément à la loi sur les finances de la Confédération, les personnes physiques qui ne font pas partie de ladministration fédérale peuvent uniquement utiliser le service de signature de la Confédération dans le cadre susmentionné. Pour ce faire, elles doivent utiliser un logiciel propriété de la Confédération et disposer dune smartcard délivrée par la SG PKI ainsi que dun ordinateur de ladministration fédérale. Développé à lintention du grand public, un validateur disponible sous www.validator.ch permet de vérifier que les identités électroniques sont conformes à la loi sur la signature électronique (SCSE).
De plus amples informations sur les signatures numériques sont disponibles sous https://www.openegov.admin.ch/egov/…
Identity and access management (IAM) systems such as eIAM perform the tasks of recognising users (identity) and, optionally, affirming their permissions in the target applications (access).
Electronic signature is not part of an IAM system's service provision. eIAM does not offer digital signatures. However, as a general rule, the services of IAM systems, or the login procedures carried out through them, can be used to generate an electronic signature via a signature service connected to the target application.
Federal Administration employees can sign electronically using the SG PKI. If the signature process based on the SG PKI is to be implemented in a federal application, the Federal Administration's standard signature service must be used. For most automatic (mass) signatures, the impersonal Federal Administration stamp is provided.
According to the Financial Budget Act, the Federal Administration's signature services can be made available to government levels outside the Federal Administration only in the context described above. Prerequisites are a federal application owned by the Confederation, an SG PKI smart card and a Federal Administration workstation. The validator application www.validator.ch, which can be used to verify electronic signatures according to the ESigA, is publicly available.
Further information for citizens is available at https://www.openegov.admin.ch/egov/…