Page principale Navigation Contenu Contact Sitemap Recherche

Connection of applications to eIAM

Procurement factsheet
V1.7 2024-10-09 ▪ Also mandatory for in-house developments and other forms of software introduction

This factsheet must be an integral part of the requirements for procurements of affected ICT solutions; it can be referenced with the URL .

This factsheet is not applicable to AGOV use by the cantons and their communes. Federal applications are not connected directly to AGOV, but rather to eIAM in accordance with this factsheet; AGOV is automatically available in the eIAM ecosystem.


For most applications, including native mobile apps, an eIAM subscription obligation applies in accordance with . Evaluate the subscription obligation for your case in the
Checklist Ⅴ’’’

expand all ▼

Ⅰ INTRODUCTION

This factsheet concerns the connection of applications to eIAM.

INTRODUCTION
Χ

Background

Web applications and native mobile apps of the Federal Administration, irrespective of the place and form of operation and protection requirements, hereinafter referred to as "applications", must obtain the authentication services from the corresponding standard service of the Federal Administration (see ). In the case of applications from the justice sector and affiliates, the FDJP's "SSO portal" service should be used; in other cases, the eIAM service is to be used (direct and indirect eIAM connection is possible; indirect connection variants: via ePortal or IAM EAER).

Usage obligation and significance for procurements

The obligation to use authentication services and the resulting exclusion of other (proprietary) IAM services, e.g. built into the applications or their operating environments (SaaS and other forms of cloud operation), mean that the ability to connect – easily if possible – to the standard service is a MANDATORY CRITERION for procurement. During the procurement process, this factsheet must be used as a source for defining the MANDATORY CRITERIA and also the OPTIONAL CRITERIA (connection simplicity aspects).

Focus of the usage obligation, scope

The usage obligation concerns the digital identities and their credential and the resulting authentication services. Thus, the applications or their operating environments (e.g. SaaS and other cloud operation forms) may maintain their own user administrations with authorisation data (rights such as roles and attributes), as long as the authentication services are exclusively obtained from eIAM.

Ⅱ CRITERIA

A distinction must be made between the basic connection possibility and the simplicity of its design.

Ⅱ’ MANDATORY CRITERIA
Χ

MANDATORY CRITERION 1: Basic connection possibility

The basic connection possibility exists if the applications can federate with eIAM via one of the following protocols:
  1. OIDC with Authorization Code Flow & PKCE (Proof Key of Code Exchange)
  2. SAML2.0 with browser POST binding
  3. SAML2.0 with browser Redirect binding
  4. WS-Federation

MANDATORY CRITERION 2: Service provider first incl. data/transport

As shown in the video at , starting at 07:00, eIAM works with the "service provider first" pattern, which means that the end user first calls up the target application, this then recognises the user as not yet being authentic and subsequently prompts the browser to redirect formally and in terms of content to eIAM according to OIDC or SAML2.0 or WS-Federation.

This includes the following statements on data/transport:

  • The application MUST* be able to initiate single logout via the federation protocol.
  • The application MUST be able to sign the authentication request (optional; only if no fixed assertion consumer service URL).
  • The application MUST* accept bearer tokens.
  • Federation messages are received and transmitted by eIAM only over connections secured with Transport Layer Security (TLS).
*If not feasible, an eIAM connection may nevertheless be possible

Ⅱ’’ OPTIONAL CRITERIA (connection simplicity aspects)
Χ

Since the point of contact to eIAM does not have to be directly on the application, but can also be a front for the operator, the following refers to the point of contact between eIAM and target instead of between eIAM and application.

OPTIONAL CRITERION 1: Use of OIDC or SAML2.0 or WS-Federation tokens according to the eIAM standard

eIAM writes specific data in specific fields in the tokens. The connection to eIAM is simplified if the target can cope with it; see documentation at .

If OPTIONAL CRITERION 1 is not fulfilled: If the target requires other fields, eIAM offers a certain flexibility (rewriting/mapping), sometimes at a cost. Target application-specific changes to the eIAM tokens (OIDC, SAML2.0, WS-Federation) must be requested via process P035 ().

OPTIONAL CRITERION 2: OIDC or SAML2.0 or WS-Federation as the only point of contact (no interfaces)

The connection is simplified if one of the aforementioned protocols is the only point of contact between eIAM and the target; in other words, if there are no interfaces between eIAM and the target in the sense that user data would have to be a) read from eIAM, b) written to eIAM, or that c) eIAM would have to send it to the target (provision) on a channel other than the token resulting from OIDC or SAML2.0 or WS-Federation.
For the target, this means that the tokens resulting from OIDC or SAML2.0 or WS-Federation are the only external source of user information and that if the target is to persist the user data, this must be done just-in-time from the tokens.

If OPTIONAL CRITERION 2 is not fulfilled: If the target requires interfaces as described in a), b) and/or c), the next section should be consulted.


Ⅱ’’’ NON-FULFILLMENT OF CRITERIA (Resolution of the resulting eIAM incompatibility)
Χ

If ICT solutions are procured, including cloud solutions such as SaaS, that cannot be connected to eIAM within the eIAM standard, the application owner is obligated to have an authentication bridge (in the form of an adapter) developed and maintained. See .

Ⅲ INTERFACES

The eIAM interfaces are not adapted to the target, rather the other way round.

INTERFACES
Χ

If the use of the interfaces listed below is necessary, FCh DTI/FOITT should be consulted as early as possible.

If interfaces as described above and below are necessary, the connection to eIAM remains possible, but the eIAM interface specifications must be followed; the eIAM interfaces are not adapted to the target, rather the other way round.

If this leads to incompatibility between the target and eIAM, and the target cannot be adapted (not all SaaS providers are always willing to do this), the connection to eIAM is at risk. Such applications should not be procured. If this is nonetheless necessary, the customer must have an adapter, i.e. a specialist bridge application (see ) developed and operated at their own expense at the FOITT or elsewhere. Such incompatibility does not automatically lead to an exemption for operation without eIAM.

Please note that mere claims by a manufacturer such as "SAML2.0 capable" or "OIDC capable" or "WS-Federation capable" are not sufficient; one example is SaaS X. This is SAML2.0 capable, but requires provisioning of users to its proprietary API; this excludes eIAM as a standard service facility from providing this proprietary provisioning (reusability requirement). An adapter was subsequently developed for SaaS X., i.e. an authentication bridge (see ).

eIAM-RDM interface

eIAM-RDM enables users to be invited in eIAM by means of a representational state transfer (REST) API. RDM stands for remote delegated management. Delegated management principally concerns the fact that it is not the person responsible for permissions in an office who assigns permissions, but someone else (see Service 6 and eIAM video at 11:00). When RDM is used, it is not a human who triggers the invitation in eIAM, but rather a machine. In both cases, eIAM sends the invited person an email that contains an invitation and an onboarding code. The invited person redeems the onboarding code once using an appropriate digital identity of their choice, which means that this digital identity is connected to the target application via eIAM.
Usage consideration: The consideration of whether to use eIAM's delegated management in general, and potentially via RDM in particular, is based on the modelling of the onboarding processes, i.e. the question "how do users access the target application for the first time" (see the ONBOARDING PROCEDURES section below).

eIAM-AMW interface

eIAM-AMW offers a Simple Object Access Protocol (SOAP) API that allows user data and organisational structures to be read and modified in eIAM. In other words, eIAM-AMW is the interface to the eIAM access client.
Usage consideration: The use of this interface is the antithesis of OPTIONAL CRITERION 2 mentioned above and reflection is recommended on how OPTIONAL CRITERION 2 could be fulfilled following the simplicity requirement.

eIAM-LDS interface

eIAM-LDS allows user data to be retrieved via the Lightweight Directory Access Protocol (LDAP). The LDAP interface is only available to applications that are operated in the Federal Administration's networks. For this purpose, eIAM makes the details of application users available in a dedicated directory.
Usage consideration: The use of this interface is the antithesis of OPTIONAL CRITERION 2 mentioned above and reflection is recommended on how OPTIONAL CRITERION 2 could be fulfilled following the simplicity requirement.

Ⅳ OTHER ASPECTS TO BE CONSIDERED

OTHER ASPECTS TO BE CONSIDERED
Χ

WITH OR WITHOUT ACCESS MANAGEMENT

Without access management (authentication only): If the target application needs to receive from eIAM solely the identity of the person logging in (for the purpose of recognition), in other words, no authorising data (roles, rights, etc.) is maintained in eIAM and no onboarding procedures are carried out in eIAM because this access management is done entirely in the target application itself, the use of an eIAM access client is not necessary, but a direct connection of the application to the federal trust broker, or BTB, as a lightweight connection procedure is advisable.

With access management: If authorising data (rights, roles, etc.) is to be maintained in whole or in part in eIAM (in order to be sent to the target application during the login process) and/or eIAM has to carry out onboarding procedures for the target application (accepting access requests from users or inviting users by email or letter, including delegated management), the use of an eIAM access client is mandatory. For the roles, rights etc. to be mapped in the eIAM access client, the following applies: firstly, the number must be manageable (not hundreds); secondly, changes (adding, removing, renaming roles, rights etc.) are not frequent (an order has to be submitted to the FOITT in each case); and thirdly, it is not necessary to dynamically import roles, rights etc. from external sources.

ONBOARDING PROCEDURES

It is recommended that the tender documentation mention the possible onboarding procedures, including the preferred ones. Onboarding describes the process that allows users to use a target application by means of their eID. The onboarding procedures are described in Service 5 at . Providers must refer to these onboarding procedures and describe how they can work with their solution. Commissioning parties and tenderers can consult the FOITT/FCh DTI on this.

INCREASED PROTECTION NEEDS

eIAM enforces the zone policies of the SZ+ and Federal Administration network zones, and allows access to these zones only after prior authentication with a QoA of at least 50.

EIAM PROVISIONING OF CLOUD SOLUTIONS

The provisioning of applications in AWS and Azure and other clouds is successful. Azure in particular defines many prerequisites. Therefore, it is recommended to involve the FOITT/FCh DTI as early as possible regarding the procurement of cloud solutions. SaaS and other cloud patterns are subject to the usage obligation .

Ⅴ CHECKLISTS

Ⅴ’ CRITERIA & ASPECTS CHECKLIST
Χ

Download Checklists V' (WORD DOCX)

 Ⅴ’ CRITERIA & ASPECTS CHECKLIST

MANDATORY CRITERION 1: Basic connection possibility
☐ Fulfilled, via protocol ____________

MANDATORY CRITERION 2: Service provider first, incl. data/transport
☐ Fulfilled, incl. data/transport

OPTIONAL CRITERION 1: Use of OIDC or SAML2.0 or WS-Federation tokens according to the eIAM standard
☐ Yes, fulfilled
☐ No, the target requires other fields/data
      (exact description by provider required, review of offers by FCh DTI and the FOITT recommended)

OPTIONAL CRITERION 2: OIDC or SAML2.0 or WS-Federation as the only point of contact (no interfaces)
☐ Yes, fulfilled
☐ No, target requires interfaces to eIAM
      (exact description by provider required, review of offers by FCh DTI and the FOITT recommended)

ACCESS MANAGEMENT
☐ Without eIAM access management (authentication only),
      i.e. no rights, roles, etc. in eIAM, everything in the target application
☐ With eIAM access management, because
☐ ☐all or ☐certain rights and roles (number: ______ ) are managed in eIAM
      and/or ☐ the onboarding procedure/ ☐ the delegated management of eIAM is used.
☐ Tenderers responded

ONBOARDING PROCEDURES
☐ Obsolete, as authentication only
☐ Preference/scenario of procurers is defined
☐ Tenderers responded

FORM OF OPERATION
At the FOITT (Atlantica, VM ...), external, SaaS, cloud solution, etc.)

☐ __________________________________________


Ⅴ’’ LOGIN PROCEDURE & QUALITY CHECKLIST
Χ

Download Checklists V'' (WORD DOCX)

 Ⅴ’’ LOGIN PROCEDURE & QUALITY CHECKLIST


In sections b) and c), "yes" should be selected only once in each.

Within sections b) and c), the requirements are listed from low to high. The high requirements can arise from business requirements, but there should be no unnecessary levelling up; instead, "only" the federal ICT directives should be fulfilled, especially Si001.

a) Login procedure:

☐yes / ☐no
Individuals with a FED-LOGIN (employees of the Federal Administration and affiliates such as certain cantonal employees) should be able to log in via FED-LOGIN.

☐yes / ☐no
Individuals without a FED-LOGIN should (also) be able to log in (partners, private individuals, etc. via AGOV, CH-LOGIN and connected third-party identity providers).

b) Authentication quality, identity verification part (also known as identity check):

☐yes / ☐no
It is sufficient if the person declares their data themselves during the login procedure (when opening the login account); no further verification.
Reason: _____________________________________________________

☐yes / ☐no
It is sufficient if the person declares their data themselves during the login procedure (when opening the login account), but the details must match a register data record (e.g. personal postal address database, HR database).
Reason: _____________________________________________________

☐yes / ☐no
The details of the person logging in must be reliable, based on an official photo ID that has been stored and compared to the person's face.
Reason: _____________________________________________________

c) Authentication quality, part concerning hardening of login factors:

☐yes / ☐no
Unhardened login factors such as passwords and text message mTANs may be used. Within the Federal Administration, Kerberos is also considered unhardened.
Reason: _____________________________________________________

☐yes / ☐no
Only hardened login factors (e.g. FIDO-based access apps, FIDO security key, smart cards) may be used.
Reason: _____________________________________________________


FCh DTI and the FOITT advise on operating forms without cost implications.


Ⅴ’’’ CHECKLIST FOR IAM PROVISION IN THE FED. ADMIN., SPECIFICATIONS AND USAGE OBLIGATION
unorthodoxesprungmarke
Χ

Download Checklists V''' (WORD DOCX)

Ⅴ’’’ CHECKLIST FOR IAM PROVISION IN THE FEDERAL ADMINISTRATION, SPECIFICATIONS, USAGE OBLIGATION

Synopsis
Χ

Identity and access management (IAM) provision in the Federal Administration refers to all processes in which an digital identity is used to authenticate the acting entity (identity), possibly followed by additional authorising information (access).

The aim of this checklist is to pinpoint requirements based on two questions:

  1. Which IAM system can/must be used?
  2. Which quality level of authentication assurance is required?

The answers to these two questions depend on various sources of information that are not easy to summarise:

For question 1, the first key factor is the usage obligation for the relevant standard service, bearing in mind that the standard service offers two services. Secondly, there are dedicated cases not covered by the usage obligation.

For question 2, the results of the protection needs analysis are the main factor, but there are also many additional considerations.

In many cases, this checklist should provide directly operational answers to both questions.

Checklist

This checklist is not specific to eIAM, but can be applied to any system in the Federal Administration. Please answer each question with "yes" or "no". The questions relate specifically to a target application or a portal with multiple target applications.

Name of application/portal: _________________________________
(referred to below as the "target"; intermediary IAM systems (e.g. ePortal, PAMS) comprising multiple applications can also be the target.)


    A. SUBJECTS
  1. ☐yes / ☐no: Do people have to log in to the target?


  2. ☐yes / ☐no: Do machines have to log in to the target?
    3. If the answer to both of these questions is "no", IAM provision is not necessary and this checklist is not applicable.
    If the answer to question 2 is "yes", please contact the Federal Chancellery’s Digital Transformation and ICT Steering Sector (FCh DTI).


    B. TARGET OBJECT (TARGET APPLICATION/TARGET)
  3. ☐yes / ☐no: Is the target a web application (i.e. does it run in a browser)?
    4. If the answer is "yes", the usage obligation applies – see (the usage obligation applies to the central Federal Administration, but decentralised units may also participate under certain conditions). This applies regardless of the host and hosting zone; SaaS such as Atlassian Cloud is also subject to the usage obligation.


  4. ☐yes / ☐no: Is the target a mobile app (for use on smartphones/tablets)?
    5. If the answer is "yes", the usage obligation applies – see (the usage obligation applies to the central Federal Administration, but decentralised units may also participate under certain conditions).


  5. ☐yes / ☐no: Is the target a client application on an end device (e.g. fat/rich client)?
    This is undesirable technology, please contact the FCh DTI.


  6. ☐yes / ☐no: Is the target a client application on a server, e.g. remotely operated via a terminal emulator such as Citrix?
    This is undesirable technology, please contact the FCh DTI.


  7. ☐yes / ☐no: Is the target an IoT entity (e.g. window blind motors, door openers, passport/ID card gates (e.g. at airport), working robots, automatic machines including software robots on BAB or other clients)?
    For IAM for IoT, please contact the FCh DTI. The usage obligation applies, but practical arrangements are still being worked out.


  8. ☐yes / ☐no: Have you answered "no" to all the above questions in section B?
    Consult the FCh DTI where applicable.


    C. RESPONSIBILITY FOR TARGET (technical application manager (AM))
  9. ☐yes / ☐no: Is the party that commissioned the target use part of the central Federal Administration or otherwise subject to the Digitisation Ordinance (DigiV)?
    10. If the answer is "no", the usage obligation from section A no longer applies. Voluntary usage for entities that are not part of the central Federal Administration (peripheral parties) is possible under certain conditions and is often recommended.


    D. PROTECTION REQUIREMENTS
    Important: The protection requirements do NOT affect the usage obligation statements in sections A to C !
  10. ☐yes / ☐no: Does the result of the protection needs analysis suggest that "basic protection" is required?
    11. If the answer is "yes", the authentication assurance must be "medium" according to Si001, and at least QoA30 according to www.eiam.admin.ch/qoa. Broken down, this means two-factor authentication (2FA) without the need to verify the subject's identity.


  11. ☐yes / ☐no: Does the result of the protection needs analysis indicate "increased protection requirements"?
    12. If the answer is "yes", the authentication assurance must be "high" according to Si001, and QoA50 according to www.eiam.admin.ch/qoa. Broken down, this means 2FA with an extra-strong second factor and substantial verification (authentication) of the subject's identity.


    E. TARGET HOSTING
    Important: The protection requirements exclude hostings that do not meet the required protection level!
  12. ☐yes / ☐no: Is the target operated in a server zone with increased protection requirements, e.g. server zone plus (SZ+) of the Federal Administration?
    13. No conclusions can be drawn in the reverse scenario. If the answer is "yes", the authentication assurance must be "high" according to Si001, and at least QoA50 according to www.eiam.admin.ch/qoa. Broken down, this means 2FA with an extra-strong second factor and substantial verification (authentication) of the subject's identity.


  13. ☐yes / ☐no: Is the target operated in another Federal Administration server zone?
    14. This has no bearing on the usage obligation results in sections A to C.


  14. ☐yes / ☐no: Is the target operated outside of the Federal Administration with an external operator, including all cloud solutions (e.g. Abraxas, Azure, AWS, Google)?
    15. This has no bearing on the usage obligation results in sections A to C.


    F. LOGIN AUDIENCE
  15. ☐yes / ☐no: Do employees of the Federal Administration (internal, external, onboarded affiliates (e.g. cantons)) need to be able to log in?
    16. If the answer is "yes", eIAM's FED-LOGIN login procedure must be used for this login audience (please note that FED-LOGIN can also be used without a smartcard being issued, see "totally smartcardless" at ). IMPORTANT: The type of login audience does NOT affect the usage obligation statements in sections A to C. This also applies to rented SaaS (e.g. Atlassian cloud solutions, Miro boards, Power BI)!


  16. ☐yes / ☐no: Do people other than those referred to in question 15 need to be able to log in? This could include members of the public and partners who have not been onboarded with FED-LOGIN (including cantons).
    17. If the answer is "yes", eIAM's AGOV login procedure (including associated third-party identity providers such as eduID, cantonal eIDs and CH-LOGIN, which is currently being phased out) must be used for this login audience. IMPORTANT: The type of login audience does NOT affect the usage obligation statements in sections A to C. This also applies to rented SaaS (e.g. Atlassian cloud solutions, Miro boards)!

  17. ☐yes / ☐no: Should holders of the Swiss state e-ID be able to authenticate themselves directly with it?
    The answer to this question has NO influence on the obligation to obtain e-ID authentications; e-ID authentications must be obtained via the standard service IAM, namely via the integral standard service IAM component AGOV. A direct connection of the e-ID to the target application for the purpose of authentication (login) is not permitted.

  18. ☐yes / ☐no: Do people with special identity providers ("sector IdPs" as per ) need to be able to log in, e.g. people in the healthcare sector using the identity provider HIN?
    19. If the answer is "yes", it is possible to apply for this to the FCh DTI. IMPORTANT: The eIAM usage obligation also applies in this case. Sector IdPs must be obtained via eIAM and must not be connected to systems (target systems, intermediary IAM systems) other than eIAM. The type of login audience does NOT affect the usage obligation statements in sections A to C. This also applies to rented SaaS (e.g. Atlassian cloud solutions, Miro boards)!


    G. ACCESSMANAGEMENT
  19. ☐yes / ☐no: Do people have to be invited by e-mail to use the target application via eIAM (e-mail with onboarding code)?
    The answer to this question has no influence on the subscription obligation. If yes, the delegated management of eIAM must be used and the answer to the follow-up question must be ‘yes’. However, the target application can handle the invitation emails itself.


  20. ☐yes / ☐no: Do people have to be assigned roles and rights in eIAM?
    The answer to this question has no influence on the subscription obligation (the subscription obligation applies to identities and authentication, but not to access management). The roles and rights can be maintained in eIAM and or in the target application, i.e. also in mixed form. Extreme versions: nothing regarding access management in eIAM, everything in the target application (eIAM = Authentication Only) versus nothing regarding access management in the target application, everything in eIAM (eIAM = with Access Mandant), i.e. the application follows the instructions in the eIAM authentication token.


    H. DIFFERENTIATION OF USAGE OBLIGATION
  21. ☐yes / ☐no: Do sections A to C indicate an obligation to use the standard service and is the target to be located in the policing/justice sector?
    22. If the answer is "yes", the FDJP's SSO Portal service, part of the Federal Administration () "Identity and Access Management" standard service, is to be used instead of eIAM.
    Both services are managed by the FCh DTI.


    I. INFORMATION ABOUT APPLICATIONS IN PORTALS
  22. For applications in portals such as EasyGov, ePortal and eGovernment DETEC, the usage obligation referred to at applies. The portal can abstract the transition to eIAM so that the individual application does not have to be connected to eIAM, but only the portal layer itself. Proprietary login procedures of the portal and direct connections from identity providers are not permitted.


    J. DETAILED INFORMATION ABOUT KERBEROS
  23. Web applications and native mobile apps may only consume Kerberos directly if an exemption has been granted. Otherwise they must go through eIAM.

  24. Other applications and office automation can consume Kerberos directly in some cases (please consult the FCh DTI).

  25. Kerberos does NOT qualify as "high" according to Si001si001 unless 1. the resource is directly integrated in a Federal Administration user forest (approval from the FCh DTI DSS/DW is required) and 2. the authentication on the client used has demonstrably enforced smartcard use (not the case on mobile VDI, for example).


    K. DETAILED INFORMATION ABOUT AGOV
  26. The central federal administration uses AGOV "direct only"* only in very rare exceptional cases requiring approval; otherwise, it uses AGOV via the "full"* eIAM. Exemptions are possible – apply via .

  27. The decentralised Federal Administration can obtain AGOV via eIAM (special conditions apply) or AGOV "direct only"*.

  28. Other Swiss authorities (cantons, communes, combined entities), assuming they are compatible with the Federal Act on the Use of Electronic Means to Carry Out Official Tasks (EMOTA), obtain AGOV "direct only"* and not AGOV via "full"* eIAM.
*
"full" eIAM schema: AGOV identity provider ➤ eIAM IAM system ➤ target application (or intermediary IAM system)
"Direct only" AGOV schema: AGOV identity provider ➤ target application (or intermediary IAM system)