Requirements for the URLs of the application

Compliance with the eIAM requirements for URLs is mandatory for applications that are operated within the networks of the Federal Administration!

Explanation parts of the URL

URLs e.g. https://www.gate.amt.admin.ch/appl1/private/ of a web application consist of a protocol part (https://) a Fully Qualified Domain Name (FQDN) part (www. gate.amt.admin.ch) and a path part (/appl1/private/) .

The following describes the specifications regarding these parts of the URL.

Entry Point FQDN

The naming of the FQDN on the eIAM-Web PEP is basically specified:
  • eIAM PEP External (federal administrative network, cantonal network and Internet).

eIAM instance FQDN
Production (PRO) www.gate.<amt>.admin.ch
Acceptance (ABN) www.gate-a.<amt>.admin.ch
Reference (REF) www.gate-r.<amt>.admin.ch


Here, a so called "Split Brain DNS" procedure ensures that the same FQDN is resolved to a different (external) IP address on the Internet than on the Federal Administration network, where the FQDN is resolved to a Federal Administrative network internal IP address. On the eIAM side, requests from the Federal Administration network are routed via different eIAM-Web PEP instances than requests from outside the Federal Administration network. However, this is transparent for the application.

Application areas

The eIAM-Web PEP represents a secure reverse proxy server in a front door version. It thus allows several specialised applications in a single sign-on domain to be addressed via the same FQDN. This requires a clean separation of the applications via the URI paths, since the eIAM-Web PEP uses the path to select the backend to which the user's http request must be sent. In order for the eIAM-Web PEP to correctly perform its function as a coarse authorisation level, application areas must be defined. Application areas are defined by the URL in the application. Application spaces, also called URI Name-spaces, can be defined with the directory structure.

Different application areas are necessary if the resources in the directory structure must be protected differently in the application.
For example, one part of the application may be accessible without authentication, while another part of the application is only accessible to authenticated and authorised users, and yet another part of the application should only be accessible with a high level of authentication.

The configuration of such a policy also applies to all subdirectories (e.g. a configuration for /appl1/private/* also applies to /appl1/private/docs/*).
If the following scheme is used for the application areas, the eIAM-Web PEP can ensure right from the start that only correctly authenticated and authorised accesses reach the application.

Example URLs for public, protected and specially protected areas:

  • /appl1/* = Context namespace of the application public area (unauthenticated)
  • /appl1/public/* = public area (unauthenticated)
  • /appl1/private/* = authenticated (requires user login) and authorised (requires coarse-grained role) area
  • /appl1/private/strong/* = authenticated (requires user login with strong authentication) and authorised area with coarse-granular role
It is important to make a clean distinction between the different URI namespaces. It is of course also possible to make access to the entire URI namespace of the application accessible only to authorised users via a coarse-granular role. It is also possible to require strong authentication for the entire application.

Rule 8: The different URI namespaces of an application with different protection needs must be structured in a simple way and must not overlap.

Overlaps occur if, for example, one wants to protect /appl1/private/* and /appl1/private/public/* differently. Within the path /appl1/private/*, which is protected in itself, there is an unprotected path ./public/*. This is not permitted.

Public

This area is public and the URL can be accessed by anyone without a user login and without checking permissions.
Resources that are to be used before user authentication must always be in an unprotected area.

Authentic and Authorised with Role APPL.ALLOW

All applications have a coarse authorisation role '<application name from eIAM-AM>.ALLOW'. If a user is to be authorised to access an application, at least this role must be assigned to him in his profile. Only with this roughly granular role does the user have any access at all to the protected areas of the application via the eIAM-Web PEP. Since this enforces that the user sending the request must have this role, a minimum strength of authentication must also be defined for each application.

eIAM uses the following qualities of authentication

Quality of Authentication (QoA)
 

Authentic and Authorised with Defined Fine-Granular Role (Option)

The eIAM service offers a 2-level role concept for access management. For example, one can additionally protect a URL and only release it for the role "Application name from eIAM-AM>.<ROLLE>". Fine granular roles must be defined in the eIAM dossier before integration.

Functionality of the eIAM roles


Authentic with strong authentication (option)

Certain parts or the whole application can be protected by requesting stronger authentication. Those protected URLs can then only be accessed if the user has logged in with a stronger authentication. Which paths must be protected with which authentication strength must be defined in the eIAM dossier before integration.

URI Namespace Management

The eIAM Web PEP does request dispatching. This means that for each request sent from the web browser to the PEP, the PEP must evaluate to which application the request must be sent. For this purpose, so-called mappings are defined on the PEP. The management of the URI namespaces is important so that the namespaces do not overlap.

The PEP can dispatch requests sent by the web browser using the following option.

  • Request Dispatching by Request URI Mapping - Standard
    • One or more URI namespaces are mapped to an application on the PEP. It is possible to create an SSO session between the applications on the PEP. This mapping is not possible if the application requires a so-called root mapping, i.e. the application expects mandatory requests in the name space /*.

    Example:
    https://www.gate.amt.admin.ch/appl1/* => https://appl1.ssz.admin.ch/appl1/*
    https://www.gate.amt.admin.ch/appl2/* => https://appl2.ssz.admin.ch/appl2/*
    https://www.gate.amt.admin.ch/appl3/* => https://appl2.ssz.admin.ch/appl3/*

Structure of a URL: <entrypoint(pep)>/<application>/<access>/<resource>
Example: https://www.gate.bit.admin.ch/myappl/private/welcome.html

Where the individual parts are defined as follows:


Key Description
<entrypoint(PEP)> Entry point depending on client
https://www.gate.amt.admin.ch
<application> URI reserved for the application, e.g.
/myappl
<access> Access type according to application area, see chapter 0, e.g.
/private
<resource> Resource within the application area
welcome.html

URI namespaces reserved by eIAM

  • /_pep/*
  • /auth/*
  • /errorpages/*
  • /login/*
  • /styles/*
  • /scripts/*
  • /images/*
  • /nevisidm/*
  • /passwordchange/*
  • /pwreset/*
  • /apstat
  • /favicon.ico
Of course, however, an application may use the namespace /appl1/public/images/*, for example.

Query parameters reserved by eIAM

The following query parameters are reserved by eIAM and may not be used by applications using the eIAM service.
  • ?login
  • ?logout