Identité, Authentification et Autorisation

Identité (Identity)

Concept d’entité unique appartenant à un système : l’Identity Manager (exemple : un utilisateur dans l’Active Directory – AD).

Une remarque concernant K2 et l’Active Directory. K2 n’est pas limité à l’AD comme User Manager (UM), on trouve aussi SQLUM ou des customs UM.

Active Directory Federation Services (ADFS) est un Identity Federation Provider (IFP), c’est-à-dire qu’en plus de jouer le rôle d’Identity Provider (Emission de jetons), il permet aussi la traduction des jetons d’authentification par revendication (claims) dans différentes versions afin de faire dialoguer plusieurs Identity Providers. Sa version Cloud est appelée Azure Access Control Service (ACS), celle de l’AD : Azure AD (AAD). L’utilité principale d’un IFP est de traduire les jetons d’authentification par revendication dans différents formats standard (SAML…).

Authentification (Authentication)

Mécanisme de vérification de l’identité.

Voici une liste des mécanismes existants et disponibles en standard avec K2 :

  • NTLM (Windows) est l’envoi d’un jeton de connexion (vérification simple). C’est le mode le plus répandu mais qui tend à être remplacé par Kerberos qui est plus sécurisé et mieux adapté aux grandes infrastructures.
  • Kerberos (Multi) est la 5e lune de Pluton l’échange d’un ticket d’authentification (vérification double). Plus robuste que NTLM il est aussi plus complexe à mettre en place (à configurer pour chaque source et destination). Son point faible est qu’il n’est pas compatible, sans Constraint Delegation, avec le web (http ou https).
    • Kerberos Constraint Delegation permet d’utiliser Kerberos pour des applications via SSL => HTTPS et de limiter les services accessibles par le web.
  • Claims (Multi) est un échange simplifié mais possible entre des domaines multiples (différents AD, différentes plateformes, à travers le web …) réalisé par l’intervention d’un Dispositif de sécurité (issuer): le Security Tocken Service (STS) dont le rôle est de fournir des jetons de sécurité.

K2 propose un mode d’authentification alternatif et spécifique à l’utilisation de ses produits : le K2 Pass-Through Authentication (PTA) afin de pallier au défaut de NTLM et de ne pas être confronté à la complexité Kerberos. La difficulté est que K2 est un centre d’échange avec des sources de données. Il doit être configuré pour s’authentifier avec les sources de données via un seul mode d’authentification. Malgré son existence, bien pratique pour un environnement de développement ou de test, nous préconisons l’utilisation de modes d’authentification plus universels pour des plateformes de production et intégration.

Autorisation (Authorization)

Permission d’un utilisateur (accès, lecture/écriture…).

Depuis longtemps géré par un serveur Windows pour les autorisations, les architectures actuelles (qui ne sont plus entièrement Windows) ne sont plus compatibles. Windows propose alors l’utilisation d’OAuth, pour Open standard to AUTHorization. Ce mode nécessite un Trust manuel lors de la première configuration (par exemple celle de l’App K2). Ce mode nécessite la présence d’un jeton en cache pour l’authentification, c’est la raison pour laquelle il y a une redirection lors du premier lancement de K2.

C’est tout pour cette fois, cheers !

benjamin

Technical Specialist @t K2 France ----- Twitter : @benjaminbertram ----- LinkedIn : Benjamin Bertram

One thought to “Identité, Authentification et Autorisation”

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.