Secure Access est utilisé pour authentifier les utilisateurs des solutions Matrix42 Core , Pro and IGA et du libre-service.

Avec Secure Access , vous pouvez authentifier en toute sécurité différents types d'utilisateurs lors de la connexion à :

1. Matrix42 Core , Pro and IGA en libre-service
2. Solutions Matrix42 Core , Pro and IGA (comme IGA , ITSM, etc.)

Vous pouvez utiliser plusieurs méthodes d’authentification différentes simultanément et les utilisateurs peuvent accéder à différents services ou solutions en fonction de l’authentification sélectionnée.

Il est également utilisé pour surveiller les activités malveillantes lors de l'authentification. Par conséquent, les protections contre les attaques par force brute et le détournement de clic sont activées par défaut.

Page de connexion

Toutes les solutions Matrix42 Core , Pro and IGA utilisent une page de connexion commune. Cette page permet de se connecter aux solutions et services libres Matrix42 Core , Pro and IGA .

Selon les protocoles d'authentification utilisés (configurables), des onglets distincts pour la connexion (à l'entreprise) et le reste des méthodes d'authentification sont affichés.

L'image d'arrière-plan et le logo au milieu de l'écran de connexion peuvent être modifiés selon les souhaits du client. Dans les captures d'écran ci-dessous, le logo et l'image d'arrière-plan par défaut Matrix42 sont utilisés. Ces modifications ne peuvent être effectuées que depuis l'hôte ESA . Si vous n'y avez pas accès, vous devez demander Matrix42 d'effectuer cette modification en suivant ces uid : Configurer les thèmes pour ESA

Options de langue

Les utilisateurs ont la possibilité de changer la langue par défaut en une autre en la choisissant dans le menu déroulant dans le coin supérieur droit.

Les langues par défaut sont : l'anglais, le finnois, le suédois et l'allemand.
Les langues disponibles sont : anglais, finnois, allemand, suédois, polonais, croate, tchèque, danois, néerlandais, estonien, français, italien, letton, lituanien, norvégien, russe, espagnol et turc.

Consoles d'administration
Lors de la définition des utilisateurs pouvant accéder à la page de connexion, configurez la tâche de provisionnement pour l'authentification dans la plateforme de gestion des services.

La configuration de l'authentification ne nécessite des modifications supplémentaires que lorsque les protocoles d'authentification sont modifiés ou que de nouveaux sont mis en service.


Le protocole d'authentification doit également être configuré dans la console d'administration Secure Access , où sont également définis les mappages d'authentification. Par exemple : https://<votre URL d'instance>/auth/admin

Secure Access ( ESA ) est une nouvelle image de marque de Keycloak ( keycloak ), une application Open Source qui fournit des services d'authentification.

Il a été personnalisé par Matrix42 comme suit :

• Les écrans de connexion sont remplacés
• Les authentificateurs personnalisés donnent accès aux solutions Matrix42 Core , Pro and IGA .

Secure Access comprend les composants suivants :

Apache

Matrix42 Core , Pro and IGA utilisent un serveur HTTP Apache comme proxy pour toutes les solutions Matrix42 Core , Pro and IGA . Lorsqu'un utilisateur ouvre un navigateur et saisit l'URL d'une solution proposée par Matrix42 Core , Pro and IGA , la requête est envoyée au serveur Apache. Si la requête est autorisée (l'utilisateur a correctement saisi ses identifiants), elle est transmise à la solution Matrix42 Core , Pro and IGA à laquelle il tente d'accéder (par exemple : ITSM, ESS, IGA ).

ESA

Secure Access propose une console d'administration permettant de configurer les exigences spécifiques de connexion des utilisateurs aux solutions Matrix42 Core , Pro and IGA . Cette console permet de configurer les informations extraites du fournisseur Pro identité (IdP) et celles envoyées aux solutions Matrix42 Core , Pro and IGA (par exemple : libre-service, ITSM, IGA , etc.).

Base de données ESA

Secure Access utilise une base de données Postgre SQL pour stocker les configurations spécifiques au client et un résumé des informations des utilisateurs qui se sont connectés à Matrix42 Core , Pro and IGA Solutions.

Chaque client de l'environnement Matrix42 Cloud , qu'il soit dédié ou privé, dispose de son propre serveur HTTP Apache dédié, configuré pour utiliser Shibboleth ( https://www.shibboleth.net ) comme fournisseur de services. Keycloak agit comme proxy du fournisseur d'identité réel, qui peut être Azure , AD , OpenLDAP ou une solution similaire.

Lorsqu'un utilisateur saisit l'URL d'une application Matrix42 Core , Pro and IGA , la requête est dirigée vers le serveur HTTP Apache du client via une entrée DNS. Ce comportement est identique, que l'environnement soit dédié ou privé. L'image ci-dessous illustre un environnement cloud dédié, attribué à un client/locataire spécifique :

Le serveur HTTP Apache de chaque client est configuré pour rediriger les requêtes non authentifiées vers Keycloak ( ESA ), qui se chargera de l'authentification. L'authentification s'effectue de l'une des manières suivantes :

• Présentation de son propre écran de connexion
  • Ceci est fait si le client utilise AD / LDAP ou si les informations d'identification de l'utilisateur sont stockées localement dans l'ESM
• Redirection du navigateur de l'utilisateur vers l'écran de connexion fourni par Azure .

Si un client utilise Azure ou AD FS, Keycloak ( ESA ) peut être configuré pour autoriser l'authentification unique (SSO). Dans ce cas, l'utilisateur n'a pas besoin de saisir à nouveau ses identifiants de connexion s'il l'a déjà fait de manière approuvée. Par exemple, l'utilisateur a allumé son ordinateur portable, configuré pour s'authentifier avec Azure / AD FS au démarrage.

ESA peut contenir plusieurs domaines différents, chacun avec sa propre méthode d'authentification. Par exemple, les utilisateurs internes peuvent utiliser leur propre méthode d'authentification, tandis que les utilisateurs externes peuvent utiliser la leur.

Surveillance
Secure Access est surveillé par le système de surveillance centralisé Matrix42 . Matrix42 dispose de plusieurs capteurs par application, garantissant qu'en cas de problème dans l'une des applications du Cloud Matrix42 , le système de surveillance génère une alerte et analyse le problème dans les meilleurs délais.
Matrix42 n'apporte aucune donnée client au système de surveillance Matrix42 .

Enregistrement
Secure Access génère un journal système, dans lequel les utilisateurs administrateurs peuvent trouver des fichiers journaux détaillés à des fins d'audit et de dépannage.

L'identité utilisateur fédérée permet d'accéder à plusieurs domaines ou applications à l'aide d'un seul ensemble d'identifiants. La pratique courante en matière de fédération d'utilisateurs consiste à lier l'identité de l'utilisateur à plusieurs systèmes de gestion des identités.

Il est très courant qu'une organisation utilise déjà un service d'annuaire pour stocker les informations d'identification et les identifiants des utilisateurs (nom d'utilisateur et mot de passe). La fédération d'utilisateurs permet d'accéder à des bases de données et annuaires externes, tels que LDAP et Active Directory .

Secure Access peut valider les informations d'identification d'un annuaire et extraire les informations d'identité de l'utilisateur pour l'authentifier auprès des solutions Efecte. L'option LDAP est prise en charge.

Vidéo de connexion

Liens vers les articles de configuration

Instructions client pour la fédération d'utilisateurs

Configurer : Fédération d'utilisateurs pour l'authentification

L'authentification unique (SSO) est une méthode d'authentification couramment utilisée, ce qui signifie que l'utilisateur n'a pas besoin d'ajouter d'informations d'identification (nom d'utilisateur et mot de passe) lors de l'authentification, mais qu'il est authentifié avec les informations d'identification reçues du Pro d'identité (IdP), généralement un répertoire comme Entra ID (anciennement Azure AD ) .

SSO peut être techniquement mis en œuvre en utilisant les protocoles SAML ou OpenID et le choix de celui utilisé varie toujours en fonction de l'IdP du client.

Exemples de protocoles d’authentification utilisés pour SSO :

AD FS ( Microsoft Active Directory Federation Service) utilise toujours le protocole SAML .

Entra ID SSO (Microsoft Azure Single-Sign-On) utilise le protocole SAML ou OpenID .

Vidéo de connexion

Liens vers les articles de configuration

Instructions client pour la configuration SAML Entra ID

Instructions client pour la configuration Entra ID OpenID

Configurer : ESA Entra ID SSO

Instructions client pour la connexion AD FS

Configurer : connexion ESA AD FS

Secure Access prend également en charge les utilisateurs locaux ESM. Un utilisateur local est une personne dont les identifiants ne sont stockés dans aucun Pro d'identité (par exemple, AD , Azure AD , OpenLDAP , etc.).

Les informations sur les utilisateurs locaux doivent être trouvées dans la solution Efecte utilisée par le client. Les utilisateurs locaux peuvent être créés manuellement depuis la configuration de la plateforme Efecte ou à l'aide du moteur de workflow.

Notez que cette même logique s’applique à toute solution construite sur la plateforme Efecte.

Vidéo de connexion

Liens vers les articles de configuration

Configurer : Effectuer la connexion de l'utilisateur local

Secure Access prend en charge la possibilité d'accorder un accès invité à Efecte Self-Service.

À partir de la page de connexion Efecte, l'utilisateur sélectionne l'authentification d'accès invité, les informations d'identification temporaires sont générées pour l'utilisateur invité et il/elle est redirigé vers Efecte Self-Service.

Les utilisateurs invités auront une visibilité limitée sur les services et informations d'Efecte Self-Service, et ne pourront pas revenir à leurs demandes ou rapports créés dans Efecte Self-Service. Pour des raisons de sécurité, il est fortement recommandé de compléter l'action ReCaptcha, c'est-à-dire de confirmer qu'il n'est pas un robot.

Vidéo de connexion - Action ReCaptcha

Liens vers les articles de configuration

Configurer : ESA - Configuration de l'accès invité

Secure Access permet la connexion anonyme. Ainsi, avant de se connecter à Efecte Self-Service, un nom d'utilisateur et un mot de passe sont générés aléatoirement. Ces utilisateurs anonymes peuvent copier leurs identifiants et les utiliser pour consulter, par exemple, l'état d'un rapport.

Secure Access et toute autre solution Efecte n'enregistrent pas les informations d'identification de l'utilisateur ni de sa session. Pour des raisons de sécurité, il est fortement recommandé de compléter l'action ReCaptcha, c'est-à-dire de confirmer qu'il n'est pas un robot.

Par exemple : la solution Efecte Whistleblower utilise la fonction de connexion anonyme.

Vidéo de connexion - Efecte Whistleblower

Liens vers les articles de configuration

Configurer : Configuration de l'accès des lanceurs d'alerte

Secure Access prend en charge le service de découverte SAML , qui est utilisé pour l'authentification Virtu.

Virtu est la solution d'authentification unique commune du gouvernement finlandais et la responsabilité du centre TIC gouvernemental Valtori, ce qui signifie que le client doit faire partie du réseau de confiance Virtu.

Depuis la page de connexion d'Efecte, l'utilisateur sélectionne le type d'authentification ou d'action à utiliser. Si l'authentification Virtu est requise, il est redirigé vers cette page. Une fois authentifié, il est redirigé vers Secure Access et peut accéder aux solutions Efecte selon ses droits d'accès.

En savoir plus sur Virtu à partir d' ici .

Liens vers les articles de configuration

Configurer : authentification ESA Virtu

Instructions client pour l'authentification Virtu

Secure Access prend en charge le service de découverte SAML , qui est utilisé pour l'authentification HAKA.

HAKA est la fédération d'identité des universités, des écoles polytechniques et des institutions de recherche finlandaises, une solution d'authentification unique commune, et la responsabilité du CSC (IT Center for Science Ltd.), ce qui signifie que le client doit faire partie du réseau de confiance HAKA.

Depuis la page de connexion d'Efecte, l'utilisateur sélectionne le type d'authentification ou d'action à utiliser. Si l'authentification HAKA est requise, il est redirigé vers cette page. Une fois authentifié, il est redirigé vers Secure Access et peut accéder aux solutions Efecte selon ses droits d'accès.

En savoir plus sur HAKA ici .

Liens vers les articles de configuration

Configurer : authentification ESA HAKA

Instructions client pour l'authentification HAKA

Secure Access prend en charge l'authentification Google .

Depuis la page de connexion d'Efecte, l'utilisateur sélectionne le type d'authentification ou d'action à utiliser. Si l'authentification Google est requise, il est redirigé vers Google page. Une fois authentifié, il est redirigé vers Secure Access et peut accéder aux solutions Efecte selon ses droits d'accès.

Vidéo de connexion

Liens vers les articles de configuration

Configurer : authentification Google ESA

Secure Access prend en charge le protocole SAML , qui est utilisé pour l'authentification Okta.

Okta est un cloud d'identité sécurisé qui relie toutes vos applications, connexions et appareils dans une structure numérique unifiée.

Depuis la page de connexion d'Efecte, l'utilisateur sélectionne le type d'authentification ou d'action à utiliser. Si l'authentification Okta est requise, il est redirigé vers cette page. Une fois authentifié, il est redirigé vers Secure Access et peut accéder aux solutions Efecte selon ses droits d'accès.

Vidéo de connexion

Liens vers les articles de configuration

Comment configurer l'authentification pour Okta ( SAML ) ?

Secure Access prend en charge le protocole OpenID , utilisé pour l'authentification Keycloak . Keycloak est une solution logicielle open source conçue pour fournir un accès unique aux applications et services. Elle permet aux utilisateurs de s'authentifier une fois et d'accéder à plusieurs applications sans avoir à ressaisir leurs identifiants.

Depuis la page de connexion d'Efecte, l'utilisateur sélectionne le type d'authentification ou d'action à utiliser. Si l'authentification Keycloak est requise, il est redirigé vers cette page. Une fois authentifié, il est redirigé vers Keycloak Secure Access et peut accéder aux solutions Efecte selon ses droits d'accès.

Liens vers les articles de configuration

Comment configurer l'authentification pour Keycloak ?

L'authentification forte est une définition qui est obtenue lorsque deux (2) des trois (3) principes suivants sont respectés lors de l'authentification,

1. Quelque chose que vous possédez (par exemple un téléphone portable)
2. Quelque chose que vous connaissez (par exemple nom d'utilisateur et mot de passe)
3. Quelque chose que vous êtes (par exemple une empreinte digitale)

De nos jours, l’authentification forte contient généralement :

1. Quelque chose que vous savez (nom d'utilisateur et mot de passe)
2. Quelque chose que vous possédez (mot de passe à usage unique pour appareil mobile)

Les principes sont ce qui différencie l'authentification forte de l'authentification à deux facteurs (2FA) et de l'authentification multifacteur, qui nécessitent seulement qu'au moins deux méthodes d'authentification soient utilisées, mais elles peuvent découler du même principe, ce qui signifie que 2FA ou MFA ne sont pas nécessairement une authentification forte.

L'exemple suivant peut être appelé MFA ou 2FA, mais pas authentification forte,

1. Quelque chose que vous savez (nom d'utilisateur et mot de passe)
2. Quelque chose que vous savez (réponses aux questions de sécurité)

Le mot de passe à usage unique (OTP) peut faire partie de l'authentification et cela signifie que le mot de passe à usage unique est envoyé à l'utilisateur par e-mail ou par SMS (envoyé sur le téléphone mobile de l'utilisateur).

Dans certains cas, il suffit de saisir uniquement le mot de passe à usage unique, mais si le client souhaite une authentification forte, il est recommandé de demander à l'utilisateur de fournir par exemple des informations d'identification (nom d'utilisateur et mot de passe) également pour l'authentification.

La fonctionnalité de mot de passe à usage unique est fournie dans tous les services Signicat , ce qui signifie qu'ils sont le partenaire d'Efecte dont la technologie est utilisée pour l'authentification.

Secure Access prend en charge l'authentification par code à usage unique, qui sont des mots de passe temporaires générés par une application d'authentification comme par exemple Google Authenticator ou FreeOTP.

Lorsqu'un mot de passe à usage unique (utilisant une application d'authentification) est configuré et que l'utilisateur a fourni ses identifiants (nom d'utilisateur et mot de passe), Secure Access lui demande de fournir le mot de passe généré par Google Authenticator ou FreeOTP. Veuillez noter que l'application d'authentification doit être installée sur le téléphone mobile de l'utilisateur.

Liens vers les articles de configuration

Configurer : authentification à deux facteurs (2FA)

L'authentification par identifiant bancaire est toujours une authentification forte, ce qui signifie que l'utilisateur utilise ses informations d'identification bancaire personnelles (fournies par la banque ou le gouvernement) pour s'authentifier auprès des solutions en libre-service ou Efecte.

Cette méthode d'authentification est courante, notamment dans les pays scandinaves, mais elle gagne également en popularité dans d'autres pays européens. Si vous avez besoin d'une authentification bancaire hors de Finlande ou de Suède, veuillez contacter Efecte pour plus d'informations.

L'authentification des identifiants bancaires s'effectue via des protocoles spécifiques à chaque pays, et Secure Access utilise les services Signicat comme intermédiaire d'identité entre les banques et Secure Access . L'authentification des identifiants bancaires est actuellement prise en charge en Finlande et en Suède.

Finlande:

En Finlande, l'authentification par identifiant bancaire est le plus souvent utilisée par les entreprises du secteur privé et dans les cas où une organisation gouvernementale, pour une raison quelconque, n'est pas en mesure d'utiliser l'authentification suomi.fi.

Suède:

En Suède, l’authentification des identifiants bancaires est couramment utilisée par les organisations gouvernementales et privées.

L'authentification Suomi.fi est similaire à l'authentification par carte bancaire, à la seule différence que suomi.fi est réservé aux organismes gouvernementaux finlandais. Vous pouvez vous identifier auprès des services à l'aide de codes bancaires en ligne finlandais, d'une carte de certificat mobile ou d'une carte de certificat.

Secure Access utilise les services Signicat comme Identity Broker, entre le service suomi.fi et Secure Access .

En savoir plus sur l'authentification suomi.fi ici .

SAML est un protocole conçu pour échanger des identités d’authentification et d’autorisation entre les domaines de sécurité.

Secure Access prend en charge l'authentification des utilisateurs effectuée par Pro d'identité (IdP), par exemple Entra ID , à l'aide d'un connecteur/adaptateur SAML 2.0.

SAML envoie les réclamations au format XML SAML . Ce format est couramment utilisé pour aider les organisations disposant de plusieurs applications à fournir une connexion unique à leurs utilisateurs finaux.

Liens vers les articles de configuration

Configurer : authentification ESA M SAML
ESA - Instructions client pour la configuration SAML Entra ID

OAuth 2.0 et OpenID Connect (une extension du protocole OAuth 2.0) permettent aux organisations de vérifier l'identité de l'utilisateur final, sur la base de l'authentification effectuée par un serveur d'autorisation, ainsi que d'obtenir des informations de profil de base sur l'utilisateur final.

Secure Access prend en charge l'authentification des utilisateurs effectuée par un Pro d'identité (IdP), par exemple Entra ID , à l'aide du connecteur/adaptateur OpenID Connect .

OpenID Connect est construit sur le protocole OAuth et envoie des réclamations en utilisant le format JSON Web Token (JWT) et il est couramment utilisé, par exemple, avec les Pro d'identité basés sur le cloud, les sites Web grand public et les applications mobiles.

Liens vers les articles de configuration

Configurer : ESA Azure AD SSO
ESA - Instructions client pour la configuration Entra ID OpenID

Le protocole SAML Discovery Service est utilisé pour l'authentification HAKA et Virtu dans Secure Access , mais il est également couramment utilisé, par exemple, dans les universités.

Liens vers les articles de configuration

Configurer : authentification ESA HAKA

Configurer : authentification ESA Virtu

Protocole du réseau de confiance finlandais utilisé pour l'authentification avec les identifiants bancaires finlandais, ainsi que pour l'authentification avec suomi.fi. Son utilisation est obligatoire ; plus d'informations sont disponibles ici .

L'authentification BankID suédoise est utilisée lors de l'authentification avec un numéro d'identification national suédois (personnummer).

Une attaque par force brute tente de deviner le mot de passe d'un utilisateur en tentant de se connecter plusieurs fois. Secure Access dispose de capacités de détection par force brute et peut désactiver temporairement un compte utilisateur si le nombre d'échecs de connexion dépasse un seuil spécifié.
En activant la détection par force brute (activée par défaut), nous pouvons bloquer temporairement les attaquants qui tentent de pénétrer dans le système. Lorsqu'un utilisateur est temporairement verrouillé et tente de se connecter, Secure Access affiche le message d'erreur par défaut indiquant un nom d'utilisateur ou un mot de passe invalide afin que l'attaquant ignore que son compte est désactivé.

Liens vers les articles de configuration

Comment activer la détection de force brute sur ESA

La protection contre le détournement de clic empêche un attaquant d'intégrer une page Web dans un iframe et d'inciter l'utilisateur à cliquer sur des boutons ou des liens cachés ou déguisés.

Par défaut, la protection contre le détournement de clic est activée par défaut.

Le client peut activer la politique relative aux cookies lors de sa connexion. Ainsi, les visiteurs du site web sont informés des données utilisateur collectées par les cookies, des raisons de ce suivi et de leur destination.

Liens vers les articles de configuration

Configurer les paramètres des cookies ESA

Le client peut activer le consentement lors de sa connexion, ce qui signifie que les utilisateurs du site web autorisent la collecte, l'utilisation et le traitement de leurs données via les cookies. Après la saisie des identifiants, ESA affichera une fenêtre identifiant le client demandant une connexion et les informations d'identité requises. L'utilisateur peut alors décider d'accéder ou non à la demande.

Liens vers les articles de configuration

Configurer ESA pour utiliser le consentement de l'utilisateur